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INTRODUCTION  AND  SUMMARY 

This  report  describes  the  results  of  the  second  portion  of  the  System 
Control  for  the  Transitional  Defense  Communications  System  study.  The 
objective  of  this  study  is  to  define  a  system  to  assist  in  responding  to 
stresses  of  the  DCS  requiring  system  wide  visibility  as  can  be  provided 
at  Theatre/ACOC.  Peace  time,  minimal  stress  scenarios  are  emphasized. 

(See  the  fit st  technical  report  for  the  scenarios  considered.) 

The  work  summarized  in  this  report  has  addressed  the  acquisition  of  data 
which  permits  stress  detection  and  isolation  and  the  correlation  and  display 
of  these  data  at  ACOC.  This  work,  and  that  reported  on  in  Technical  Report 
No.  1,  comprise  task  1  of  the  study.  The  second  task  will  address  the 
selection  and  activiation  of  system  level  controls  in  response  to  detected 
stresses. 

1.1  STUDY  BASELINE 

The  focus  of  the  study  is  the  DCS  anticipated  to  exist  in  Europe  in  the  mid 
I960' s.  The  European  DCS  is  used  because  it  is  as  complex  as  any  other 
segment  of  the  DCS  and  contains  examples  of  every  type  of  subsystem  used  in 
the  DCS.  The  European  area  is  reflective  of  user  and  mission  objectives 
world  wide.  Results  can  be  extended  to  other  theatres.  The  European  DCS 
of  the  mid  1980's  is  assumed  to  consist  of: 

o  A  Digital  European  Backbone  using  microwave  radios  and  multiplex 
equipment  compatible  with  the  DRAMA  specifications  and  digital 
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tropo-scatter  radios  and  monitored  by  an  ATEC  system  consistent 
with  the  ESD  ATEC  10000  specification. 

o  The  Defense  Satellite  Communication  System  (DSCS)  using  the 

DSCS  III  satellite  and  under  the  control  of  equipment  specified  in 
the  DSCS  Control  Segment  (CS)  specifications. 

o  An  integrated  AUT0V0N/AUT0SEV0C0M  II  system  using  TTC-39  switches 
and  SB-3865  concentrators. 

o  An  AUTODIN  II  System  using  three  switches  identical  to  those 
being  developed  for  use  in  CONUS,  to  replace  the  existing  AUTODIN 
switches. 

The  TTC-39  and  SB-3865  were  planned  for  upgraded  AUT0V0N/AUT0SEV0C0M  II  at 
the  time  this  study  was  started.  The  decision  not  to  use  these  equipments 
occurred  after  this  work  was  completed. 

The  first  technical  report  described  the  configuration  of  these  systems  in 
Europe  used  as  the  baseline  for  this  study.  Appendix  A  of  this  report 
summarizes  significant  characteristics  of  these  systems. 

1.2  RECOMMENDED  SYSTEM  CONTROL  SYSTEM 

A  system  integrating  the  control  capabilities  of  the  subject  subsystems  has 
been  recommended.  The  data  gathering  capabilities  of  each  subsystem  have 
been  used  to  provide  data  necessary  for  system  level  control  of  the  DCS. 
Particularly,  the  data  must  support  detection,  isolation,  and  response  to 
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system  level  stresses.  Thus,  correlation  to  detect  and  Isolate  stresses 
beyond  that  done  at  lower  levels  of  the  DCS  hierarchy  Is  required.  This 
includes  correlation  of  reports  from  multiple  AUTOVON  switches,  and  between 
the  switched  networks  and  the  transmission  network. 

Specific  CRT  displays  are  provided  which  highlight  the  cause  of  the  stress 
rather  than  merely  presenting  all  of  the  stress  indications.  Additional 
CRT  displays  provide  the  comprehensive  status  and  current  allocation  of  the 
DCS  resources.  These  support  the  selection  of  appropriate  controls  to 
minimize  the  impact  of  the  stress. 

The  software  and  a  host  computer  system  to  support  the  data  correlation  and 
displays  at  ACOC  level  have  been  characterized.  In  addition,  the  modifica¬ 
tions  to  planned  subsystems  in  order  to  acquire  the  necessary  data  and  the 
means  of  telemetering  that  data  to  ACOC  have  been  characterized.  ATEC,  DSCS 
CS,  and  AUTODIN  II  are  planned  to  report  data  to  ACOC,  therefore  requiring 
little  change. 

For  ATEC  and  the  DSCS  CS,  it  is  recommended  that  changes  in  status  of 
special  interest  circuits,  trunks,  links  and  stations  be  made  upon  completion 
of  fault  isolation,  which  is  more  an  elaboration  of  operating  policy,  than 
a  change  to  those  subsystems.  This  will  make  available  to  the  System  Controller 
comprehensive  system  status. 


For  AUTODIN  II,  a  Subnetwork  Control  Center,  which  is  a  copy  of  the  Network 
Control  Center  is  recommended  for  use  at  ACOC  Europe. 

This  will  permit  focussed  attention  on  the  operation  of  European  AUTODIN  II, 
and  will  allow  continued  control  of  that  network  even  when  isolated  from 
CONUS. 

Acquisition  of  data  from  the  TTC-39  is  recommended  to  be  via  the  SYSCON 
channel  and  a  channel  acquisition  equipment.  This  will  be  either  a  Channel 
Reconfiguration  Model  or  a  SYSCON  Channel  Acquisition  Unit.  All  channels 

are  collected  at  a  central  site  where  they  are  routed  into  a  Report 
Consolidation  Processor,  and  then  onto  a  dedicated  circuit  to  ACOC. 

The  SB-3865  is  modified  to  provide  messages  defined  by  ICD-004  in  an  ATEC 
format.  These  messages  are  routed  into  an  ATEC  Communications  Interface 
Set  (CIS)  and  through  ATEC  to  ACOC. 

Budgetary  estimates  of  the  costs  of  the  required  equipment  and  modifications 
have  been  made.  These  are  summarized  in  Table  1-1. 

The  recommended  system  and  supporting  analyses  are  described  in  the  balance 
of  the  report. 

1.3  REPORT  OVERVIEW 

Section  II  is  a  functional  description  of  the  recommended  system.  It 
Includes  a  summary  of  the  philosophy  of  real  time  system  level  control  of 
the  DCS  which  guides  this  study.  It  then  describes  the  components  of  the 
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recommended  system,  how  they  are  Integrated,  the  ACOC  level  displays,  and 
the  supporting  algorithms.  Finally,  scenarios  demonstrating  the  use  of  the 
system  are  presented. 

Section  III  presents  the  design  rationale.  Particular  subjects  include  the 
subsystem  interfaces  and  telemetry  for  AUTOVON,  the  use  of  a  Subnetwork 
Control  Center  for  AUTODIN  II  in  Europe,  and  the  integration  of  the  DSCS 
Operational  Control  function  into  the  recommended  ACOC  level  system.  Finally, 
the  contents  of  the  required  data  bases  are  described. 

Section  IV  presents  the  Functional  design  of  the  software  and  hardware 
required  for  the  recommended  system.  It  concludes  with  the  sizing  and 
costing  of  that  software  and  hardware. 

Section  V  contains  the  analysis  of  the  parameters  available  from  each  sub¬ 
system  and  the  selection  of  those  required  at  ACOC  for  system  level  control. 
The  resulting  information  flow  is  also  analyzed. 

Appendix  A  describes  the  aspects  of  the  DCS  subsystems  being  considered 
which  are  important  to  System  Control.  Particularly,  data  available  and 
controls  which  may  be  remotely  executed  are  identified. 

Appendix  B  provides  the  detailed  results  of  the  software  sizing. 

Appendix  C  describes  events  associated  with  four  stress  scenarios.  This 
illustrates  how  the  system  will  respond  to  stresses. 
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SECTION  II 


SYSTEM  FUNCTIONAL  DESCRIPTION 


2.0  INTRODUCTION 

A  functional  description  of  the  proposed  System  Control,  integrating  the 
mid  1980's  subsystem,  is  presented  in  this  section.  The  first  subsection 
summarizes  the  philosophy  of  real-time  system  level  control  which  guides  this 
study.  This  philosophy  is  the  basis  for  selecting  the  data  reported,  the 
algorithms,  the  displays,  and  the  data  base  for  the  recommended  system. 

The  second  subsection  describes  the  components  of  the  total  System  Control 
system  and  how  they  are  Integrated  to  provide  the  information  flows  required. 

The  third  subsection  sunmarizes  the  displays  proposed  for  use  at  ACOC. 

These  are  presented  here  because  they  define  the  information  required  by  the 
controllers  in  order  to  make  control  decisions.  Therefore,  they  define  the 
data  which  must  be  sent  to  ACOC,  the  processing  required  to  reduce  the  data 
to  its  most  usable  form,  and  data  bases  required  in  the  course  of  that 
processing.  Note  that  the  next  task  of  the  study  will  investigate  how  the 
control  decisions  can  be  aided  by  automation.  The  same  information  will  be 
necessary  for  the  automated  decisions,  so  that  the  results  of  the  current 
task  will  not  be  significantly  Impacted. 

The  performance  assessment,  stress  detection,  and  stress  isolation  algorithms 
which  support  the  displays  are  described  in  the  fourth  subsection. 
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Finally,  the  operation  of  the  proposed  system  is  demonstrated  via  several 
scenarios  tracing  events  from  the  initial  outage  through  informing  the 
operator  who  must  take  action. 

2.1  SYSTEM  CONTROL  PHILOSOPHY 

The  purpose  of  this  study  is  to  define  a  System  Control  system  for  the  DCS 
which  will  provide  a  capability  for  rapid  restoral  of  critical  user  circuits. 
The  general  control  philosophy  we  are  following  is  to  permit  accomplishment 
of  System  Control  functions  at  the  lowest  feasible  levels  in  the  control 
hiearchy.  Then,  as  problems  occur  which  can't  be  handled  at  a  particular 
level,  they  will  "bubbleup"  as  high  as  required  for  resolution. 

The  capability  for  real  time  System  Control  already  exists  or  is  being 
developed  for  the  System  Control  elements  below  the  Theatre  level.  Therefore, 
this  study  is  oriented  to  solving  those  real  time  System  Control  functions 
which  reach  the  Theatre  level  (ACOC). 

The  Theatre  level  System  Control  activities  envisioned  in  the  area  of  Net¬ 
work  Connectivity  Control  will  occur  in  response  to  a  request  from  Sector 
level  personnel  for  assistance  in  handling  an  outage.  This  will  occur  if  a 
Critical  Restoral  Plan  is  not  applicable  in  a  stress  situation.  The  Theatre 
level  will  revise  the  restoral  plan  to  fit  the  current  situation  with  the 
assistance  of  its  computer  system.  The  recommended  restoral  will  be  sent  to 
the  Sector.  The  Sector  will  direct  the  connection  of  the  alternate  circuit 
and  test  it  before  it  is  placed  in  service. 


The  Theatre  level  will  also  generate  restoral  plans,  again  assisted  by  the 
computer  system.  It  may  revise  those  plans  as  necessitated  by  the  current 
status  of  the  communication  system. 

The  functions  of  selection  or  modification  of  restoral  plans  are  direct 
extensions  of  the  circuit  allocation  function  already  performed  at  the 
Theatre.  Therefore,  the  personnel  there  have  the  requisite  training  for 
these  tasks.  The  data  required  for  these  functions  are  the  configuration 
and  status  of  the  transmission  system  resources. 

The  Theatre  level  AUTOVON  control  functions  envisioned  include  the  ability 
to  test  restoral  plans  before  they  are  actually  implemented.  This  would  use 
a  model  of  AUTOVON  which  could  be  configured  to  represent  the  proposed 
restoral  plan.  The  model  would  then  be  exercised  to  determine  its  performance. 
The  data  reguired  for  this  function  are  the  configuration,  status  and  loading 
of  the  AUTOVON  as  provided  by  the  recommended  system. 

2.2  THE  COMPONENTS  OF  THE  SYSTEM  CONTROL  SYSTEM 

The  components  which  are  integrated  by  the  recommended  system  are  shown  in 
Figure  2-1.  These  are  the  equipments  expected  to  be  used  in  the  mid  1980's 
DCS.  They  include: 

o  The  AUTODIN  II  Network  Control  Center  (NCC),  a  recommended  Sub¬ 
network  Control  Center  (SNCC)  which  is  a  copy  of  the  NCC  super¬ 
vising  the  European  AUTODIN  II  system  only,  and  the  Packet 
Switching  Node. 


SYSCON 

CHANNEL 

ACQUISITION 

UNIT 
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o  The  DCAOC  where  world  wide  DCS  control  is  exercised, 
o  The  ACOC  where  Theatre  wide  control  is  exercised  and  the  level 
at  which  system  wide  control  can  be  exercised, 
o  The  Upgraded  AUT0V0N/AUT0SEV0C0M  II  components  (the  TTC-39 
and  SB-3865). 

o  The  ATEC  components  -  the  Sector  Control  Subsystem  (SCS),  Nodal 
Control  Subsystem  (NCS),  the  Communications  Interface  Subsystem 
(CIS)  and  the  Measurement  Acquisition  Subsystem  (MAS), 
o  The  DSCS  Control  Segment  Components  -  the  Network  Control  Element 
(NCE),  and  the  Terminal  Control  Element  (TCE). 

The  Operations  Control  Element  (OCE)  of  the  DCSC  Control  Segment  has  been 
integrated  into  the  Network  Connectivity  Control  function  implemented  in 
WWOLS,  and  is,  therefore,  not  shown  as  an  individual  component. 

Two  components  shown  have  been  added  to  facilitate  the  interfaces  to  the 
AUTOVON  components.  These  are  the  SYSCON  channel  acquisition  unit  (SCAU) 
and  the  Report  Consolidation  Processor  (RCP). 

The  interfaces  between  all  of  the  components  are  discussed  briefly  in  the 
following  sentences.  Those  which  are  already  specified  are  not  discussed 
further,  while  the  new  or  changed  ones  are  discussed  further  in  Section  III. 

NCC/DCAOC  -  This  is  planned  as  part  of  DIN  II  and  WWOLS  upgrade.  It  supports 
55-1  reporting  by  DIN  II.  No  added  data  flow  has  been  recommended. 
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2.  NCC/SNCC  -  This  is  a  new  interface  which  uses  DIN  II.  It  forwards  European 
PSN  reports  to  NCC  and  handles  NCC/SNCC  communications.  Contents  of  the 
connection  are: 

o  PSN/NCC  messages  from  three  switches, 
o  SNCC/NCC  intercommunications. 

3.  SNCC/WWOLS  (ACOC  EUR)  This  is  a  new  interface  which  uses  DIN  II.  This 
interface  method  was  chosed  because  both  units  are  anticipated  to  have  DIN 
II  connectivity  and  will,  therefore,  be  compatible.  This  connection  handles 
the  European  subset  of  the  data  transferred  across  interface  1  above.  Data 
flow  supports: 

o  Stress  isolation  (data  to  WWOLS  identifies  transmission  faults 
identified  by  DIN,  data  from  WWOLS  identifies  transmission 
faults  identified  by  ATEC  and  the  DSCS-CS). 
o  Requests  for  added  transmission  service  from  SNCC. 
o  Grants  of  added  transmission  service  from  WWOLS. 

4.  SNCC/PSN  -  This  interface  is  the  same  as  the  standard  DIN  II  data  flow  from 
PSN  to  NCC. 

5.  ATEC  SCS/ACOC,  EUR  -  This  interface  is  defined  by  the  ATEC  10000  specifications 
although  the  contents  are  not  specified  there.  Besides  reporting  the  ATEC 
results,  the  SB-3865  switch  data  will  also  flow  across  this  interface. 

6-  DSCS  NCE/ACOC  -  This  interface  is  effectively  the  NCE/OCE  interface  described 
in  the  DSCS  CS  specification,  since  the  OCE  function  has  been  integrated  into 


ACOC/WWOLS.  Details  of  interface  and  data  content  are  not  specified  by  the 
DSCS  CS.  Use  of  ADCCP  protocols  is  recommended.  The  DSCS  CS  specification 
permits  the  OCE  to  request  any  data  from  the  NCE's  it  interfaces,  and  may 
send  requests  for  transmission  service  to  the  NCE.  A  recommended  addition 
is  to  report  by  exception  on  failures  of  significance  to  Theatre  level  control. 

7.  DSCS  NCE/DSCS  TCE  -  This  interface  is  specified  in  the  DSCS  CS  speci¬ 
fication.  Data  flow  is  per  the  specification. 

8.  SCS/NCS  -  This  interface  is  specified  in  the  ATEC  10000  specification. 
Additional  data  which  will  pass  over  it  is  SB-3865  reports  and  directives. 

The  data  which  already  passes  over  it  for  ATEC  is  not  expected  to  change. 

9.  TTC-39/SYSC0N  Channel  Acquisition  Unit  and  Report  Consolidation  Processor  - 
This  is  a  new  interface  to  route  TTC-39  messages  and  directives  through 
the  System  Control  hierarchy.  A  special  unit  to  intercept  messages  from 
the  SYSCON  channel  of  the  interswitch  trunks  is  required*  This  could  be 

a  Channel  Reconfiguration  Unit  or  hardware  specifically  serving  this 
purpose.  All  of  these  units  will  be  at  the  Langerkopf  switch.  A  Report 
Consolidation  processor  will  accept  the  SYSCON  channels  and  forward  them 
to  ACOC.  See  Section  III  for  details. 
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10.  SB-3865/ATEC  CIS  -  This  is  a  reconmended  interface  to  gather  SB-3865  data 
into  System  Control.  IDC-004  messages  and  an  ATEC  interface  protocol  is 
used.  <  See  Section  III  for  details. 


1,1.  ATEC  NCS/ATEC  CIS  -  This  interface  is  included  in  the  ATEC  10000  specifi¬ 
cation.  It  will  now  carry  SB-3865  data  as  well  as  normal  ATEC  data. 

12.  DSCS  TCE/Terrestr4al  Node  or  Station  -  This  interface  is  described  in  DSCS/CS 
specifications.  Voice  and  data  orderwires  are  provided  by  the  terrestrial 
DCS.  It  will  be  used  for  local  DSCS/ terrestrial  DCS  coordination  and  also 
to  interface  the  Terminal  Control  Processor  in  the  DSCS  TCE  to  an  ATEC  CIS. 

2.3  DISPLAYS  AT  ACOC 

The  CRT  displays  defined  for  ACOC  Network  Connectivity  and  AUTOVON  Control 
were  developed  by  a  combination  of  techniques.  These  included  studying  the 
displays  to  be  used  in  the  ATEC  system,  the  AUTODIN  II  Network  Control  Center 
and  the  development  of  a  status  file  at  ACOC  upon  receipt  of  55-1  status  reports. 
Also,  the  data  available  from  the  ATEC  system,  the  DSCS  Control  Segment,  the 
TTC-39  switch  and  the  ULS  was  evaluated.  In  addition,  various  stress 
scenarios  were  analyzed  to  determine  that  the  data  required  to  fully  Inform 
the  controller  are  available.  See  the  last  subsection  of  this  section  for 
examples  of  several  scenarios. 

The  following  subsections  describe  the  displays  to  support  AUT0V0N/AUT0SEV0C0M 
Control  and  Network  Connectivity  Control. 
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2.3.1  AUTOVON/AUTOSEVOCOM  Displays 

A  hierarchy  chart  of  the  displays  provided  for  the  AUTOVON  controller  is 
shown  in  Figure  2-2.  Included  in  the  hierarchy  are  only  those  displays 
dealing  with  the  real  time  System  Control  functions.  Other,  more  general 
man/machine  interface  functions  also  exist,  but  they  are  not  being  defined 
here.  The  hierarchy  of  displays  and  the  display  formats  are  similar  to  those 
provided  for  AUTODIN  II.  Although  these  networks  may  have  different  control¬ 
lers,  the  similarity  of  display  presentation  could  reduce  training  require¬ 
ments  for  network  operators.  The  AUTODIN  II  displays  do  provide  access  to 
large  amounts  of  information  using  a  standard  keyboard/display  terminal. 

The  top  display  in  the  AUTOVON  display  hierarchy,  shown  in  Figure  2-3,  is 
a  summary  of  the  entire  system  status.  It  is  a  very  simple  display  which 
indicates  either  normal  (shown  as  +)  conditions  or  a  basic  anomaly  in  traffic, 
switch  equipment,  trunk  status,  user  access  status,  or  switch  messages.  Its 
prime  purpose  is  to  provide  an  overview  of  the  entire  system  and  direct  the 
controller  to  more  detailed  displays  at  lower  levels  in  the  hierarchy.  The 
categories  shown  in  the  summary  display  correspond  to  the  categories  at  the 
next  level  in  the  display  hierarchy. 

The  traffic  status  summary  (Figure  2-4)  shows  the  overall  state  of  network 
performance  at  each  switch.  The  categories  reported  on  are  the  following: 
o  Priority  calls  -  the  network  is  specified  to  be  Flash  non-blocking. 

If  a  Flash  or  higher  precedence  call  Is  blocked,  the  area  controller 
must  be  made  aware  that  the  network  has  failed. 


2-9 


Figure  2-2.  AUTOS EVOCOM/AUTOVON  Display  Hierarchy 
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Figure  2-3.  Network  Status  Summary  Display 
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Figure  2-3.  Network  Performance  Summary  Display 
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0  Dial  tone  delay  -  The  dial  tone  delay  Is  one  Indicator  of  local 
switch  congestion.  By  being  aware  of  local  switch  conditions,  the 
area  controller  can  avoid  making  control  actions  which  would 
aggravate  the  local  conditions. 

0  Trunk  blocking  -  The  basic  traffic  measurement  in  the  network. 

P  Common  equipment  blocking  -  Another  indicator  of  local  congestion. 

0  Processor  load  -  Total  processor  load  must  be  maintained  below  100%. 

If  local  controls  cannot  keep  processor  utilization  down,  area  level 
must  take  some  action  to  do  so. 

More  details  on  the  traffic  are  obtainable  by  examining  the  hourly  node 
traffic  summary  (Figure  2-E)  and  its  history  file.  This  display  breaks  out 
the  calls  processed  by  the  switch  by  the  source  of  the  call.  It  is  used 
by  the  controller  to  determine  whether  or  not  routing  controls  can  alleviate 
switch  stress. 

The  trunk  traffic  status  (Figure  2-6)  shows  the  basic  traffic  parameters  on 
each  trunk  group  in  the  network.  It  is  detailed  backup  for  traffic  overload 
alarms  which  the  controller  might  wish  to  examine  before  taking  control 
actions.  Even  greater  detail  is  provided  by  the  trunk  traffic  detail  dis¬ 
play  (Figure  2-7).  This  display  breaks  out  by  precedence  how  many  calls 
were  attempted,  blocked,  and  preempted,  and  the  cause  of  the  blockage. 

The  preformance  prediction  display  (Figure 2-8}  uses  the  current  network  con¬ 
figuration  and  the  normal  busy  hour  traffic  demand  to  show  busy  hour  node¬ 
node  Grade  of  Service.  By  examining  this  display,  the  controller  can 
quickly  determine  where  the  weak  points  In  the  network  are,  and  whether 
or  not  they  are  within  acceptable  performance  ranges. 
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Figure  2-6.  Trunk  Traffic  Status  Display 
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Figure  2-8.  Performance  Prediction  -  Busy  Hour  Display 


The  next  major  category  of  displays  Is  the  switch  equipment  displays.  The 
switch  equipment  failure  summary  (Figure  2-9)  provides  the  controller  the 
status  of  all  switch  equipment  at  a  glance.  Items  with  standby  redundancy 
show  either  (+)  for  nominal  condition,  (HAZ)  for  hazardous  condition  i.e. 
single  failure,  or  (ALARM)  for  complete  failure.  Items  of  common  equipment 
have  the  number  of  failed  equipments  followed  by  the  number  of  total  equipments 
so  that,  for  example,  in  Figure  2-9  there  is  one  of  four  trunk  signalling  buffers 
failed  at  Schoenfeld.  If  the  entire  common  equipment  function  Is  lost,  the 
display  indicates  alarm,  as  Is  shown  for  LKG's  at  Donnersberg  in  Figure  2-9. 
Details  of  any  failure  are  obtainable  from  lower  level  files. 

The  switch  failure  detail  (Figure  2-10)  contains  a  log  of  all  recent  failure 
messages  for  a  given  switch,  along  with  an  analysis  of  the  effect  on  the  network. 
The  switch  failure  history  file  (Figure  2-11)  accumulates  the  operational  and 
nonoperational  times  for  equipment  items  and  displays  basic  statistics  related 
to  these  times.  By  referencing  this  display,  the  controller  can  see  how  long 
it  usually  takes  the  local  switch  personnel  to  restore  or  repair  the  item. 

Some  judgement  can  then  be  made  as  to  whether  or  not  take  centralized  control 
actions.  If  the  network  Is  not  too  badly  Impaired  and  the  fault  type  is  nor¬ 
mally  restored  quickly,  no  action  at  ACOC  Is  justified. 

The  switch  equipment  online  and  standby  Is  similar  to  the  switch  status 
summary,  except  that  the  actual  numbers  of  equipments  are  used  rather  than 
generalized  symbols.  It  is  more  difficult  to  get  a  general  idea  of  network 
status  from  this  display  because  of  Its  extra  detail,  but  it  Is  needed  for 
that  same  reason. 
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SWITCH  EQUIPMENT  FAILURE  SUMMARY 
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Figure  2-9.  Switch  Equipment  Failure 
Summary  Display 
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Figure  2-10.  Switch  Equipment  Detail  Display 


SWITCH  EQUIPMENT  FAILURE  HISTORY  -  HUMOSA 
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Figure  2-11.  Switch  Equipment  Failure 
History  Display 
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The  switch  configuration  summary  contains  basic  Information  from  the  local 
switch  data  base  such  as  the  routing  table,  the  status  of  traffic  controls, 
and  the  call  inhibit  tables.  This  display  is  referenced  by  the  controller 
to  determine  the  switch  configuration  before  initiating  controls  to  modify 
it.  The  controller  would  otherwise  have  to  remember  all  deviations  from 
normal  network  configuration. 

The  trunk  status  summary  (Figure  2-12)  provides  an  overall  summary  of  trunk 
faults  and  traffic  overloads.  By  referencing  this  display,  the  controller 
can  immediately  determine  what  transmission  resources  are  available.  For 
any  alarmed  trunk  group,  a  trunk  group  fault  detail  display  (Figure  2-13) 
is  available  which  holds  the  last  12  change  reports  (or  the  past  24  hours 
worth)  referring  to  the  trunk  group. 

The  user  access  display  group  contains  the  status  of  critical  subscriber's 
access  circuits.  The  report  status  summary  display  indicates  the  presence 
of  text  messages  and  reports  overdue  from  the  switches.  The  report  interval 
table  displays  the  time  between  schedule  reports,  and  the  report  out¬ 
standing  detail  display  shows  any  reports  that  are  overdue.  Text  messages 
are  available  from  the  text  message  display. 

2.3.2  Network  Connectivity  Displays 

The  displays  provided  to  conmunlcate  Network  Connectivity  related  information 
to  the  operator  are  listed  in  Figure  2-14.  The  information  contained  in 
these  displays  includes  the  current  status  of  the  transmission  system, 
reporting  status,  and  an  inventory  of  transmission  system  resources  (i.e., 
channels)  and  their  use.  The  transmission  system  and  reporting  status  dis- 
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TRUNK  STATUS  SUMMARY 
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Figure  2-12.  Trunk  Status  Summary  Display 
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Figure  2-13.  Trunk  Group  Fault  Detail  Display 
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Figure  2^14.  Network  Connectivity  Controller  Display  Hierarchy 


plays  are  the  means  for  conveying  the  results  of  performance  assessment, 
stress  detection,  and  Isolation.  The  Inventory  Is  essential  for  selecting 
control  actions.  These  displays  are  described  In  the  following  paragraphs. 


Connectivity  Path  Status— This  display  summarizes  the  status  of  the 
entire  European  backbone.  It  is  modeled  after  the  connectivity  path 
displays  used  by  ATEC  to  convey  an  end-to-end  path  defined  by  a  set  of 
connecting  links.  The  proposed  connectivity  paths  to  be  used  for  overall 
Europe  are  those  which  interconnect  all  pairs  of  backbone  branch  points 
and  major  nodes  (specifically  switches).  A  graphical  representation  of  this 
display  using  standard  alphanumeric  symbols  is  shown  in  Figure  2-15*  In 
this  display  there  has  been  a  failure  at  Rhein  Main.  The  use  of  a  flashing 
pound  sign  and  station  identifier  would  highlight  this  problem.  The  [p] 
indicates  that  this  is  a  partial  failure  affecting  the  DON-RMN  link.  Further 
detail  on  this  fault  can  be  called  up  by  the  operator.  This  would  be  the 
connectivity  path  disturbance  detail,  discussed  below. 

Disturbances  to  tails  off  of  the  backbone  will  be  indicated  on  this  display. 
Also,  station  level  faults  and  hazardous  conditions  can  be  indicated.  Note 
that  this  display  combines  terrestrial  and  DSCS  transmission  resources. 

Critical  Connectivity  Path  Disturbances— The  Critical  Connectivity 
Path  Disturbances  display  is  a  list  of  all  connectivity  path  disturbances  which 
have  interrupted  critical  subscribers.  The  distinctions  between  it  and  the 
connectivity  path  status  display  described  above  are:  1)  that  it  lists  only 
the  facilities  or  capabilities  which  have  reported  disturbances,  and  2)  that 
it  orders  the  disturbances  by  the  extent  of  critical  service  interruption  and 
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Figure  2-15.  Connectivity  Summary  Display 
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elapsed  time  of  the  interruption.  This  display  also  permits  accessing  the 
Connectivity  Path  Disturbance  Detail. 

Connectivity  Path  Disturbance  Detail— An  example  of  this  display  is  shown 
in  Figure  2-15.  This  is  based  on  the  ATEC  displays  (ATEC  1000  specification). 

It  includes  a  graphical  presentation  of  the  connectivity  path  identifying  the 
terminating  facilities  for  any  failure/disturbance.  The  highest  restoration 
priority  (RP)  out  of  service  (OOS)  is  listed.  Beneath  this  is  a  line  for 
each  report  related  to  the  disturbance.  In  the  example,  based  on  scenario  9, 
report  number  6  indicates  a  group  level  disturbance  (Severity  (SEV)  =  GP). 

The  degree  (DEG)  of  the  disturbance  is  Red  (R).  The  Ident  of  the  group  is 
44  JM09.  The  locations  reporting  the  outage  are  Donnersberg  and  Feldberg 
(The  group  is  out  in  both  directions.)  The  disturbance  is  on  Super  Group  B, 
Group  7.  All  channels  are  affected.  Comments  indicate  that  the  cause  is 
equipment  at  Donnersberg.  This  indicates  that  the  reason  for  outage  has  been 
sent  to  ACOC.  The  initial  report  is  the  output  of  automated  fault  isolation, 
and  would  not  include  an  RFO,  though  it  could  include  the  location  of  the 
fault.  The  estimated  time  to  repair  the  fault  is  30  minutes,  and  the  time 
that  the  report  was  made  is  0730. 

The  other  report  line  is  a  later  report  indicating  that  Group  7  Is  also  out 
of  service.  At  the  time  of  this  report,  no  comments  on  the  ETR  have  been 
reported. 
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Figure  2-16.  Connectivity  Path  Detail  Display 


The  complete  report  can  be  obtained  by  calling  up  the  Report  Detail  display 
for  the  report. 

Station  Disturbance  Sunmary— This  display  will  Include  summary  lines 
for  all  disturbance  reports  from  a  specific  station.  These  lines  are  the 
same  as  in  the  Connectivity  Path  Disturbance  Summary.  The  only  difference 
is  that  all  these  from  a  particular  station  are  grouped. 

Impact  Summary- -This  is  a  list  of  the  number  of  special  interest  and 
priority  one  and  two  circuits  of  each  type  of  service  which  are  out  of  service 
due  to  a  disturbance.  See  Figure  2-17..  This  display  will  be  updated 
whenever  a  circuit  is  restored  to  service  via  altrouting.  This  display  gives 
a  quick  summary  of  the  Impact  of  a  disturbance. 

Impact  Detail— This  is  a  list  of  special  interest  and  priority  one  and 
two  circuits  out  of  service  due  to  a  disturbance.  It  is  used  to  identify 
specific  circuits  impacted  or  to  select  specific  circuits  for  reporting. 

Reporting  Disturbance  Summary— This  display  identifies  any  Sectors  or 
NCEs  which  have  not  submitted  reports  to  ACOC  on  schedule.  This  Includes 
keep  alive  reports  required  to  assure  that  communications  to  Sectors  and  NCEs 
have  not  been  disrupted.  The  display  also  identifies  any  Sector  or  NCE  which 
has  lost  contact  with  subordinate  Nodes  or  TCEs. 

Reporting  Disturbance  Detail— This  display  is  for  a  single  Sector  or 
NCE.  It  lists  each  report  which  Is  overdue,  and  each  subordinate  site  which 
Is  out  of  contact.  Any  communication  system  disturbance  which  could  cause  the 
failure  to  report  is  identified.  See  Figure  2-18. 
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CRITICAL  SERVICE  IMPACT  SUMMARY 


Figure  2-17.  Critical  Service  Impact  Summary  Display 


Figure  2-18.  Reporting  Disturbance  Detail  Display 


Report  Index— This  is  a  list  of  all  transmission  system  reports  sub¬ 
mitted  to  ACOC.  The  operator  can  call  up  any  of  these  reports  for  any  reporting 
station,  link,  trunk,  or  circuit.  See  Figure  2-19.  When^a  specific  report 

and  station  or  link/trunk/circuit  is  selected,  the  operator  must  scan  all 
of  the  reports  of  that  category  still  resident  in  the  computer  system. 

Reports  will  be  saved  for  the  past  24  hours  or  until  the  disturbance  has 
cleared,  whichever  is  longer. 

Report  Detail— These  displays  allow  the  operator  to  review  the  selected 
report. 

The  following  displays  fall  into  the  category  of  Network  Resource  inventory. 

This  category  of  displays  encompasses  a  variety  of  access  techniques  for  the 
circuit,  trunk  and  link  data  bases,  and  the  Critical  Restoral  Plans.  This 
data  is  used  for  selecting  the  reroute  strategies  and  adding  connectivity. 

Each  display  is  described  below. 

Station  Resource  Summary- -A  listing  of  links  terminating  at  a  station, 
their  destination,  their  status,  and  the  availability  of  spare  groups  or 
circuits. 

Link  Detail --The  source,  destination  and  status  of  a  specified  link, 
the  identification  of  the  trunk  using  each  group,  and  the  quantity  and 
identification  number  of  spare  circuits  on  each  trunk. 

Trunk  Detail --The  source,  destination,  and  status  of  the  specified 
trunk,  the  list  of  links  on  which  it  rides,  and  the  list  of  circuits  riding 
on  it.  The  associated  CCSD  if  it  is  a  VFCT. 
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Figure  2-19.  Report  Index  Display 
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Circuit  Detai1--The  source,  destination,  and  status  of  the  specified 
circuit,  the  list  of  trunks  on  which  it  rides  and  associated  channel  number. 
If  it  is  a  VFCT,  includes  the  associated  trunk  number  and  list  of  subchannels 

Multiplex  Diagrams— Graphical  representation  of  interconnection  of 
groups  between  links  at  a  station. 

Critical  Restoral  Plan— Critical  Restoral  Plan  for  a  specified  circuit, 
trunk,  link  or  site. 

Connectivity  Resources~Li sting  of  circuit  segments  identified  by 
trunk  number,  channel  number  and  interrupted  CCSD  which  can  be  used  to 
establish  a  connection  between  two  specified  sites.  This  function  can  be 
used  by  circuit  engineering  by  including  a  specification  that  the  connection 
may  use  only  spare  capabilities. 

2.4  PERFORMANCE  ASSESSMENT,  STRESS  DETECTION  AND  ISOLATION 
Performance  assessment,  stress  detection  and  stress  isolation  (PA/SD/I)  is 
defined  as  the  processing  done  on  data  from  the  DCS  subsystems  to  provide 
the  most  usable  information  to  the  control  functions.  The  algorithms  used 
for  performance  assessment,  stress  detection  and  isolation  are,  therefore, 
defined  by  the  types  of  displays  required. 

Real  time  performance  assessment  occurs  continuously.  It  involves  the 
collection  and  formatting  of  data  to  determine  the  quality  of  performance 
of  the  DCS.  It  includes  monitoring  1)  status  indicators  such  as  in  frame 
synchronization/out  of  framesynchronlzation  or  switch  operational/switch 
failed,  and  2)  continuously  variable  indicators  such  as  received  signal 
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level  or  traffic  offered  to  a  switch  or  trunk  group. 

Stress  detection  involves  reporting  that  status  indicators  have  changed 
states,  or  that  continuously  variable  indicators  have  exceeded  thresholds. 

The  thresholds  can  be  selected  to  indicate  that  a  parameter  is  trending 
toward  a  problem  ("amber"  or  "warning"),  or  that  #  problem  exists  ("red" 
or  "alarm").  The  function  of  stress  detection  is  done  within  the  subsystems 
in  some  cases.  It  will  be  augmented  by  ACOC  level  algorithms  in  other  cases. 

Stress  isolation  is  required  because  some  stress  indicators  can  be  caused 
by  multiple  stresses.  This  is  analagous  to  fault  isolation  in  ATEC. 

Examples  of  stress  isolation  are: 

o  Correlating  an  AUTOVON  trunk  outage  report  with  the  ATEC  indicated 
status  of  the  carrying  transmission  system  to  determine  whether 
the  AUTOVON  problem  is  caused  by  the  transmission  system. 

o  Correlating  status  reports  for  trunks  between  one  particular  switch 
and  each  other  switch  to  determine  if  the  particular  switch  is  not 
communicating  with  any  other  switch;  and  is,  therefore,  isolated 
or  out  of  service. 

The  following  subsections  discuss  performance  assessment,  stress  detection 
and  isolation  for: 

o  Upgraded  AUT0V0N/AUT0SEV0C0M  II 
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o  AUTODIN  II 


o  The  Transmission  Network  (the  DSCS  and  Terrestrial  Transmission 
systems) 

2.4.1  AUTOVON/AUTOSEVOCOM  PA/SD/I 

AUTOVON  performance  assessment  Is  performed  primarily  at  ACOC.  Theatre  is 
the  lowest  level  In  the  hierarchy  that  has  visibility  of  the  entire  network. 
It  is  the  lowest  level  that  can  observe  the  effect  of  and  determine 
appropriate  response  to  network  stress  because  the  effects  of  stresses  and 
control  responses  tend  to  diffuse  throughout  the  network.  Typical  stresses 
detected  and  appropriate  control  responses  are  shown  in  Table  2-1. 

The  first  stress  shown,  loss  of  access  connectivity,  is  not  supported  by 
parameters  sent  to  ACOC.  However,  It  also  does  not  impact  the  performance 
of  the  network  as  a  whole  and  there  is  no  action  that  could  be  taken  from 
ACOC  to  respond  to  it.  Restoration  of  access  connectivity  is  primarily 
a  local  tech  control  function.  Local  alarms  are  sounded  at  the  TTC-39 
switch  if  access  connectivity  is  lost,  which  will  aid  in  the  prompt  resotral 
of  the  access  circuit. 


There  are  parameters  supporting  the  detection  of  a  loss  of  trunk  connectivity. 
A  message  Is  Issued  by  the  TTC-39  whenever  it  finds  that  It  is  unable  to 
use  a  trunk  group.  This  report  could  be  correlated  with  transmission  system 
performance  monitoring  data  at  lower  levels,  but  there  are  several  factors 
which  taken  together  suggest  that  this  correlation  should  occur  at  area. 
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These  factors  are  as  follows: 

1)  There  is  a  significant  time  lag  between  when  the  switch  discovers  it 
cannot  use  the  trunk  group  and  the  time  at  which  ATEC  fault  isolates 
a  problem  and  determines  that  an  AUTOVON  trunk  is  impacted. 

2)  Whether  or  not  a  transmission  problem  is  the  cause  of  the  trunk  group 
failure,  there  is  a  trunk  group  failure  in  AUTOVON.  It  could  be 
caused,  for  example,  by  the  station  wiring  between  the  switch  and 
the  MDF.  In  this  case,  ATEC  would  never  report  a  problem  but  the 
trunk  group  has  failed  nonetheless.  The  area  control  function 
therefore  needs  the  TTC-39  report  regardless  of  the  actual  status 

of  the  transmission  system. 

3)  The  trunk  group  failure  report  is  ambiguous,  in  that  the  TTC-39 
will  report  a  trunk  group  failure  in  response  to  a  transmission 
problem,  or  the  failure  of  the  distant  end  switch.  It  does  this 
because  the  switch  does  not  have  sufficient  visibility  to  tell  the 
difference  between  these  two  events. 

ACOC  is  the  lowest  level  which  can  resolve  the  message  ambiguity.  It  can 
do  this  quite  easily  be  correlating  the  trunk  group  failure  alarms  from 
throughout  the  network.  The  algorithm  required  to  perform  this  correlation 
is  shown  in  Figure  2-20.  if  the  transmission  system  has  failed  (in  either 


direction)  the  switches  on  each  end  of  the  trunk  group  will  report  a  trunk 
failure.  If  both  switches  do  report  the  failure,  they  will  do  It  (almost) 
instantaneously,  before  ATEC  has  had  a  chance  to  fault  isolate  the  problem. 
However,  further  confirmation  of  the  fault  can  eventually  be  obtained  from 
ATEC  data  in  most  cases  so  it  is  reasonable  to  wait  for  ATEC  correlation 
before  alarming  the  controller. 

Another  possibility  which  would  cause  the  same  message  type  to  flow  would 
be  the  complete  failure  of  the  distant  end  switch.  In  this  case,  the 
correlating  data  is  a  similar  message  from  all  of  the  switches  which  have 
trunks  to  the  distant  end  switch,  and  an  absence  of  normal  message  traffic 
from  the  distant  end  switch.  The  last  possibility  is  that  for  some  reason 
the  distant  end  switch  is  still  reporting  traffic  but  not  passing  any  traffic. 
Reasons  for  this  would  either  be  the  failure  of  all  of  the  switch's  trunk 
groups  or  some  pathological  switch  failure  mode.  These  two  cases  can  be 
separated  by  correlating  with  ATEC  data. 

Other  equipment  failures  less  drastic  than  complete  switch  failure  would  not 
prevent  the  switch  from  carrying  traffic.  However,  the  theatre  level  control 
function  must  be  congnizant  of  any  switch  degradations  to  prevent  overloading 
the  degraded  switch  or  creating  vulnerabilities  in  responding  to  other  net¬ 
work  problems.  For  example,  if  the  Martlesham  Heath  switch  failed,  a  normal 
restoral  strategy  might  rehome  its  critical  subscribers  to  Hillingdon.  But  if 
Hillingdon  had  most  of  Its  digit  receivers  In  a  failed  condition,  the  extra 
originating  load  caused  by  the  users  normally  homed  on  Martlesham  Heath 
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could  overload  the  remaining  capacity  at  Hillingdon.  In  this  case,  a  better 
response  to  the  stress  would  be  to  rehome  to  Feldberg  and  Schoenfeld,  even 
though  this  causes  a  large  amount  of  transmission  resource  for  access  circuits. 

Traffic  overload  refers  to  the  situation  where  the  demand  for  service  exceeds 
the  nominal  busy  hour  demand  due  to  some  event  independent  of  the  network 
itself,  such  as  a  military  crisis.  If  there  is  a  traffic  overload  in  one 
part  of  the  network,  the  controller  may  wait  to  change  the  routing  to 
shift  traffic  away  from  that  part  of  the  network.  Certainly,  the  controller 
needs  to  be  aware  that  some  part  of  the  network  is  heavily  loaded  so  that 
control  actions  which  shift  traffic  to  that  part  of  the  network  are  avoided. 

If  the  entire  network  is  overloaded,  better  overall  service  can  be  provided 
by  restricting  routine  users  to  primary  routing  only.  Because  of  these  items, 

a  means  for  determining  the  traffic  status  must  be  provided  to  the  control 
function. 

As  shown  in  the  parameter  selection,  call  attempts  and  overflows  on  the 
trunk  groups  provides  the  appropriate  data  for  determining  traffic  status. 

For  the  convenience  of  the  controller,  these  parameters  are  converted  to 
call  congestion  in  two  ways.  The  first  measure  of  call  congestion  is  the 
theoretical  value  computed  from  the  Erlang  B  blocking  formula.  If  the 
traffic  is  close  to  Poisson,  this  formula  will  closely  predict  the  trunk 
blocking  from  the  number  of  attempts.  Because  of  the  routing  strategy 
of  AUTOVON,  the  traffic  is  normally  close  to  Poisson.  Another  measure  of 
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call  congestion  Is  the  observed  value,  which  Is  the  number  of  overflows 
divided  by  the  number  of  attempts.  Figure  "2-21  Illustrates  the  computation 
and  use  of  these  computed  values.  They  are  compared  sequentially  to  two 
thresholds.  If  the  lower  threshold  Is  exceeded,  a  warning  flag  in  the 
status  file  Is  raised,  but  no  alarm  sounded.  An  alarm  Is  Issued  if  the 
upper  threshold  is  crossed.  These  thresholds  are  not  constants,  but  are 
related  to  equipment  status.  Any  time  a  change  in  trunk  or  switch  equip¬ 
ment  is  detected,  as  described  previously,  or  when  new  busy  hour  traffic 
requirements  are  entered,  a  set  of  thresholds  related  to  the  expected 
call  congestion  on  the  trunks  is  computed  as  an  output  of  the  network 
performance  prediction  algorithm. 

The  network  performance  prediction  (Figure  2-22)  prevents  traffic  alarms 
from  being  issued  in  response  to  equipment  status  changes.  If  the 
performance  of  the  network  in  normal  traffic  peaks  will  be  unacceptable, 
network  performance  prediction  will  detect  and  alarm  that.  It  then  sets 
thresholds  for  the  call  congestion  routine  so  that  a  duplicate  alarm 
Is  avoided  when  the  network  performance  degrades  to  its  predicted  value. 

2.4.2  AUTODIN  II  PA/SD/I 

PA/SD/I  for  AUTODIN  II  Is  handled  within  the  planned  Packet  Switching  Nodes 
(PSN's)  and  Network  Control  Center  (NCC). 

The  PSN's  In  Europe  will  necessarily  coordinate  with  the  transmission 
system  to  Isolate  faults  which  exist  between  PSN's  or  on  access  lines.  Of 


2-43 


. 

ATTEMPTS  »  ATTEI 
(ATTEMPTS 
OVERFLOWS  *0VE 
(OVERFLOW 

MPTS  +  KA* 

i-Z) 

RFLOWS+  KO* 

/VS  -  Z) 

CC1  =  E2  (ATTEMPT 

CC2  -  OVERFLOWS/ 

■  - - 

SI 

ATTEMPTS 
- — 1 

Figure  2-21.  Traffic  Thresholding  Algorithm 


consequence  for  Network  wide  control  Is  the  status  of  the  Interswitch  trunks 
and  high  priority  access  lines  as  well  as  the  offered  traffic  and  any  delays 
or  backups.  These  data  are  sent  to  the  NCC  by  each  PSN.  An  extensive  com¬ 
plement  of  displays  to  present  the  data  Is  defined  for  NCC.  See  Reference  7. 

Significant  events  are  reported  to  DCAOC  via  55-1  reports.  The  subjects 
reported  are  listed  in  Table  2-2.  The  recommended  system  will  use  an  SNCC 
in  Europe  with  the  same  capabilities  as  the  NCC.  This  will  report  via 
55-1 s  to  ACOC.  These  are  used  to  develop  an  overall  European  DCS  status 
display  supported  by  the  real  time  System  Control  computer  at  ACOC.  Faults 
in  the  transmission  system  which  impact  AUTODON  II  can  be  reported  to  the 
SNCC  on  the  same  telemetry  path  as  the  55-1 s  use.  At  the  discretion  of  the 
SNCC  operator,  this  information  can  be  passed  to  the  PSN's. 


2.4.3  Transmission  Network  PA/SD/I 

The  transmission  network  PA/SD/I  will  be  supported  by  the  Control  Segment 
for  the  DSCS  and  by  ATEC  for  the  terrestrial  transmission  system.  The 
transmission  network  PA/SD/I  functions  performed  at  ACOC  are: 

o  Assessment  of  overall  transmission  network  status 
o  Determining  If  a  station  is  Isolated  or  out  of  service 

Assessment  of  overall  transmission  network  status  Is  supported  by  the 
parameters  required  from  the  transmission  systems.  Specifically,  any 
station,  link,  trunk  or  critical  circuit  failures  or  degradations  must  be 
reported  upon  the  completion  of  fault  Isolation.  These  data  are  formatted 
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TABLE  2-2.  ITEMS  REPORTED  FROM  AUTODIN  II  NCC  TO  WWOLS 


Items  which  are  trended: 
o  Blockages  recorded 
o  Preemptions 
o  Buffer  utilization 
o  Processing  delays 
o  Timeouts 
o  Retransmissions 


Items  reported  as  a  result  of  status  changes: 
o  PSN 

o  Access  line 
o  1ST 

o  Critical  Switch  function 

-Switch  buffering  allocation 
-Source  switch  connection  control 
-Source  switch  control  for  access  denial 
-Destination  switch  timeout  control 
-Switch  directory  table  update 
-Switch  outage  and  reload 
-Interlace  detection 
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into  the  Network  Connectivity  displays  discussed  previously.  These  displays 
will  be  used  to  determine  if  a  special  response  to  a  fault  is  required. 

The  special  response  will  be  ACOC  direction  of  restoral,  taking  into  account 
the  overall  transmission  network  status. 

The  DSCS  Control  Segment  specification  defines  the  parameters  to  be 
monitored  and  calculated  in  the  Control  Segment.  These  parameters  will  in 
general  be  available  on  demand  from  the  OCE  which, in  the  recommended  system, 
is  integrated  into  the  overall  Network  Control  function  at  ACOC.  An 
additional  requirement  to  report  changes  in  status  of  the  station,  link, 
trunk,  or  critical  circuit  has  been  imposed  on  the  Control  Segment.  The 
equipment  status  defined  in  the  Control  Segment  specification  must  be 
translated  to  the  affected  link,  trunk,  or  circuit  before  reporting.  In 

addition,  fault  isolation  must  be  completed,  to  assure  that  only  the  highest 
level  fault  is  reported.  There  is  no  requirement  for  this  function  in  the 
available  Control  Segment  specifications. 

The  ATEC  10000  specification  requires  monitoring  the  terrestrial  trans¬ 
mission  system  to  obtain  the  necessary  link,  trunk  and  circuit  status. 

Fault  isolation  is  required,  so  that  only  the  highest  level  fault  need 
be  reported. 
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The  recommended  operation  of  ATEC  is  that  a  change  in  state  of  a  link, 
trunk,  or  high  priority  circuit  be  reported  to  ACOC  after  fault  isolation 
has  been  completed. 

The  data  received  from  ATEC  and  the  Control  Segment  will  be  used  to  determine 
if  a  site  is  totally  isolated  or  out  of  service.  An  algorithm  for  this 

is  shown  in  Fiqure  2-23.  Mote  that  the  report  must  have  the  status  as  rein  • 
from  both  ends  or  in  both  directions  of  the  link  and  the  status  of  the 
telemetry  to  the  end  sites  in  order  to  compile  this  algorithm. 

Additional  algorithms  necessary  for  the  Transmission  Network  include  the 
transmission  fault  correlator,  shown  in  Figure  2-24.  ihis  includes  a  five 
minute  delay  if  the  first  test  proves  negative  because  of  the  potential 
delay  in  ATEC  completing  fault  isolation.  It  also  includes  a  request  of 
a  Monitor  Immediate  of  the  circuit  because  if  the  fault  was  at  circuit  level, 
there  could  be  a  15  minute  delay  until  ATEC  does  an  in-service  test. 

Finally  Figure  2-25  illustrates  the  data  base  and  display  updating  which  will 
be  done  in  response  to  an  outage  report. 

2.5  SCENARIOS 

The  following  scenarios  demonstrate  the  response  of  the  recommended  System 
Control  capabilities  to  system  level  stress.  Selection  methodology  and  a 
complete  list  of  scenarios  are  contained  in  the  first  technical  report. 

Further  details  of  the  scenarios  are  contained  in  Appendix  C. 
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Figure  2-25.  Data  Base  and  Display  Updating  for  the  Transmission  System 
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Node  Outage  (Scenario  Two) -The  DCS  station  at  Feldberg  is  totally  destroyed 
during  normal  peak  busy  hour.  The  equipment  destroyed  includes  the  TTC-39 
switch,  all  RF  and  multiplex  equipment,  emergency  power  equipment,  distribution 
frames,  antennal  and  tower  equipment.  The  events  that  occur  following  that 
destruction  are  as  follows: 


Event  Time  Description 

00:00:00.0  Feldberg  station  experiences  complete  failure. 


00:00:00.1  All  adjacent  switches  issue  R30  messages  indicating 
failure  of  the  Feldberg  trunk  group. 

00:00:00.2  Transmission  system  alarms  are  detected  by  the  ATEC 
ARS  elements.  ATEC  fault  isolation  begins. 


00:00:02  Switch  reports  arrive  at  ACOC.  Trunk  fault  correlation 

algorithm  Identifies  the  stress  as  a  node  failure  at 
Feldberg,  but  no  alarm  Is  Issued  because  traffic 
parameter  reports  are  not  overdue.  The  summary  display, 
trunk  status  display,  and  trunk  fault  detail  displays 
for  each  affected  trunk  group  are  updated  to  reflect 
the  report  arrivals. 
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Event  Time 


00:02:00 


00:03:00 


00:03:30 


00:03:45 


00:05:00 


Description 

ATEC  fault  isolation  determines  failure  of  all  links 
to  Feldberg  whose  monitoring  stations  report  to  a 
working  node.  Link  failure  messages  are  sent  to  AC0C 
from  Stuttgart  and  Langerkopf  sectors. 

ATEC  fault  isolation  terminates.  ACOC  determines  that 
transmission  failures  have  isolated  the  Feldberg  station. 
Connectivity  control  is  alarmed. 

Traffic  reports  from  Feldberg  become  overdue,  completing 
the  AUTOVON  fault  isolation  routine.  AUTOVON  controller 
is  alarmed  that  Feldberg  has  failed. 

Data  base  access  finds  the  list  of  critical  circuits 
interrupted  and  prepares  display  for  connectivity  controller. 

AUTOVON  controller  directs  the  Donnersberg  switch  to  take 
over  DSCS  circuits  and  become  gateway.  All  routing  tables 
are  updated  to  reflect  the  new  routing. 

Local  tech  controllers  at  Pirmasens,  Landstuhl,  Berlin, 
and  Bocksberg  Initiate  pre-planned  restoral  actions  to 
restore  the  3  AUTODIN  access  circuits  and  the  comnand  and 
control  circuit  via  DSCS. 

All  AUTOVON  switches  are  now  operating  with  new  routing. 
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00:10:00  AUT00IN  access  and  command  and  control  circuits  are 

patched  through  DSCS. 

The  repairs  necessary  In  this  scenario  are  so  extensive  and  gradual  that 
return  of  the  system  to  its  nominal  capacity  Is  not  part  of  the  scenario. 


Node  Outage  with  Major  System  Control  Telemetry  Failure  (Scenario  29) — The 
system  stress  In  this  scenario  is  identical  to  the  previous  scenario  (Scenario 
Two),  except  that  the  sector-sector  telemetry  and  the  sector-area  telemetry 
at  Langerkopf  also  fails  simultaneously.  Without  manual  data  transfer  and 
correlation,  ATEC  is  unable  to  fault  isolate  this  scenario.  The  events  which 
would  occur  are  as  follows: 


Event  Time  Description 

00:00:00.0  Feldberg  station  experiences  complete  failure.  Langerkopf 
sector  has  a  failure  of  the  communication  line  controller 
on  the  ATEC  processor. 

00:00:00.1  All  adjacent  switches  issue  R30  messages  indicating 
failure  of  the  Feldberg  trunk  group. 


00:00:00.2  Transmission  system  alarms  are  detected  by  the  ATEC  ARS 
elements.  ATEC  fault  isolation  begins.  ATEC  telemetry 
alarms  are  detected  at  HIN  and  S6T. 
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Event  Time 


00:00:02 


00:02:00 


00:03:00 


00:03:30 


00:03:45 


Description 

Switch  and  ATEC  telemetry  alarm  reports  arrive  at  ACOC. 
Trunk  fault  correlation  algorithm  identifies  the  stress 
as  a  node  failure  at  Feldberg,  but  no  alarm  is  issued 
because  traffic  parameter  reports  are  not  overdue. 

The  summary  display,  trunk  status  display,  and  trunk 
fault  detail  displays  for  each  affected  group  are  up¬ 
dated  to  reflect  the  report  arrivals.  Connectivity 
controller  contacts  Langerkopf  sector  on  the  order  wire 
to  obtain  verbal  status  updates. 


ATEC  fault  isloation  determines  failure  of  Link  M0293. 

Link  failure  message  is  sent  to  ACOC  from  Stuttgart  sector. 


ATEC  fault  isolation  terminates.  Link  M0293  is  the 
only  link  failure  reported  to  ACOC.  Langerkopf  verbally 
reports  failures  of  links  M0083  and  M0891,  and  unisolated 
MUX  framing  alarm  at  Donnersberg. 


Traffic  reports  from  Feldberg  become  overdue,  completing 
the  AUTOVON  fault  isolation  routine.  AUTOVON  controller 
is  alarmed  that  Feldberg  has  failed. 


AUTOVON  controller  directs  the  Donnersberg  switch  to 
take  over  DSCS  circuits  and  become  gateway.  All  routing 
tables  are  updated  to  reflect  the  new  routing. 
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Event  Time 


Description 

00:05:00  Area  controller  manually  enters  fault  data  from  Langerkopf 

sector.  This  causes  failure  analysis  algorithms  to 
determine  that  Feldberg  is  isolated  and  initiates  data 
base  search  for  critical  circuits. 


00:08:00  Upon  direction  from  the  AC9C  connectivity  controller, 

local  tech  controllers  at  Pirmasens,  Landstuhl,  Berlin 
and  Bocksberg  initiate  pre-planned  restoral  actions  to 
restore  the  3  AUTODIN  access  circuits  and  the  command 
and  control  circuit  via  DSCS. 

All  AUTOVON  switches  are  now  operating  with  new  routing. 

00:13:00  AUTODIN  access  and  command  and  control  circuits  are 

patched  through  DSCS. 


As  with  Scenario  Two,  the  repairs  necessary  in  this  scenario  are  so  extensive 
and  gradual  that  return  of  the  system  to  its  nominal  capacity  is  not  part  of 
the  scenario. 


AUTOVON  Trunk  Group  Failure  (Scenario  Nine)— The  RF  link  between  Donnersberg 
and  Rhein  Main,  Germany  fails  due  to  antenna  malfunction,  interrupting  the 
most  heavily  loaded  intra-European  AUTOVON  trunk  group.  The  subject  of  the 
scenario  is  the  AUTOVON  trunk  group,  the  link  failure  has  other  collateral 
stresses  in  addition  to  the  trunk  group  stress.  The  events  that  occur  when 
the  link  fails  are  as  follows: 
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Event  Time 
00:00:00.0 

00:00:00.1 

00:00:02.0 

00:00:03.1 

00:02:00 

00:02:30 


Description 

RF  link  from  Donnersberg  to  Rhein  Main  fails. 

Switches  at  Donnersberg  and  Feldberg  issue  trunk  group 
failure  reports. 

ATEC  alarm  reports  of  loss  of  RSL  and  multiplex  framing 
alarm  at  Rhein  Main  and  Donnersberg  arrive  at  Feldberg 
and  Donnersberg  nodes  respectively. 

Switch  reports  arrive  at  area.  Trunk  fault  correlation 
algorithm  makes  a  preliminary  decision  that  there  is  a 
transmission  fault  and  updates  its  displays  to  indicate 
that. 

Langerkopf  reports  failure  of  Donnersberg-Rhein  Main 
link  to  area,  confirming  the  trunk  fault  correlation 
algorithm's  preliminary  decision.  AUT0V0N  controller 
is  alarmed. 

o 

Data  base  access  to  Donnersberg  node  reveals  the  C 
and  weather  fax  collateral  stress,  and  requests 
Langerkopf  sector  to  check  on  the  availability  of 
links  in  the  pre-planned  altroute. 
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Event  Time 


00:03:00 


00:03:30 


00:03:35 


00:04:00 


00:08:20 


00:10:00 


06:00:00 


06:00:02 


Description 


Area  determines  routing  table  changes  for  Donnersberg, 
Feldberg,  Schoenfeld,  and  Marti esham  Heath  switches, 
and  issues  system  control  messages  to  those  switches 
via  telemetry. 

Donnersberg  receives  status  of  pre-planned  altroute,and 
initiates  patching.  Donnersberg  also  sends  patch 
coordination  to  Langerkopf. 


Donnersberg  sends  patch  instruction  to  Feldberg  node 
via  Stuttgart  sector. 


Donnersberg  switch  executes  loop  test  to  Rhein  Main  ULS, 
activating  a  local  alarm  at  Donnersberg.  Since  restoral 
activity  has  not  already  been  completed,  alarm  is  ignored. 

Real  time  traffic  reports  from  Donnersberg  and  Feldberg 
Indicating  stress  arrive  at  area.  Since  control  action 
is  already  completed,  no  further  action  is  taken. 

2 

Patching  C  and  weather  fax  is  completed. 

Link  restored. 


Donnersberg  and  Feldberg  report  restoral  of  trunk  group 
to  area. 
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Event  Time  Description 

06:01:00  Donnersberg  notifies  Langerkopf  to  return  to  normal 

configuration;Langerkopf  notifies  Feldberg  via  Stuttgart. 

06:01:30  Area  broadcasts  message  to  Donnersberg,  Feldberg,  Schoenfeld 

and  Martlesham  Heath  to  return  to  normal  routing  tables. 

At  this  time,  the  stress  situation  is  over  and  the  network  returned  to  normal 
operation. 

Partial  AUT0V0N  Trunk  Group  Failure  (Scenario  10)*-- First  level  multiplex 
failures  between  Donnersberg  and  Feldberg  interrupt  18  of  the  30  analog  IST's 
and  all  the  digital  IST's  between  Donnersberg  and  Feldberg  at  normal  busy  hour. 
This  scenario  demonstrates  the  difference  between  a  complete  trunk  group  failure 
as  in  Scenario  Nine  and  a  partial  failure.  This  scenario  as  described  assumes 
that  the  TTC-39  switch  does  not  automatically  attempt  to  use  in  band  signalling 
when  the  common  channel  signalling  fails.  The  TTC-39  hardware  would  support 
an  automatic  attempt  to  use  In  band  signalling  since  all  switch  terminations 
are  monitored  by  the  scanners,  and  in  band  signalling  receivers  are  terminated 
directly  on  the  switch  matrix.  If  the  software  were  modified  to  provide 
automatic  changeover  to  in  band  signalling,  several  of  the  detailed  reactions 
of  the  system  would  be  different  from  those  described  here.  The  events  which 
occur  following  the  multiplex  failures  are  as  follows: 


Event  Time 
00:00:00.0 


00:00:00.1 


00:00:00.2 

00:00:01.8 


00:02:03 


00:02:40 


"1 


Description 

Digroup  7  of  the  DON-RMN-FEL  B  mission  bit  stream  fails, 
causing  the  loss  of  18  of  30  analog  and  all  10  digital 
trunks  between  DON  and  FEL, 

AUTOVON  switches  at  FEL  and  DON  issue  R30  trunk  group 
failure  messages.  These  messages  enter  the  ATEC  system 
at  their  respective  nodes. 

ATEC  ARS  elements  at  FEL  and  DON  detect  multiplex  loss 
of  frame  alarms  on  D1 group  7-B. 

Switch  reports  arrive  at  ACOC.  Trunk  fault  correlation 
algorithm  tentatively  identifies  fault  as  a  trunk  group 
failure,  seeks  transmission  system  confirmation.  Summary 
display,  trunk  status  display,  and  trunk  fault  detail 
display  are  updated  to  reflect  the  message  arrivals  and 
preliminary  fault  identification. 

ATEC  fault  isolation  terminates  without  identifying 
the  cause  of  the  fault.  The  loss  of  frame  alarms,  still 
present,  are  reported  to  ACOC. 

Connectivity  control  function  determines  that  the  loss 
of  frame  alarms  correspond  to  part  of  the  recently  failed 
AUTOVON  trunk  group,  but  that  part  of  the  group  is  not 
affected. 
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Event  Time 


00:02:41 


00:05:23 


00:10:00 


0C  :ll:30 


01:25:00 


01:30:00 


01:32:30 


AUTOVON  fault  correlation  algorithm  determines  that  the 
trunk  group  failure  alarm  would  be  caused  by  the  confirmed 
circuit  failure,  but  that  a  portion  of  the  group  is  still 
usable.  A  trunk  group  modification  directive  010  is  issued 
to  FEL  and  DON  switches  directing  them  to  reconfigure  the 
remaining  trunks  into  a  usable  trunk  group. 

Switch  supervisors  at  DON  and  FEL  complete  the  trunk 
group  reconfiguration  and  place  the  group  or.  line. 

R30  messages  from  DON  and  FEL,  indicating  the  new  trunk 
group  on  line,  are  sent  to  ACOC. 

FEL  and  DON  maintenance  determine  that  the  multiplexer 
at  FEL  is  the  problem  based  on  local  alarms  at  both  ends. 

BITE  functions  executed  in  the  FEL  multiplex  indicate 
a  faulty  circuit  card. 

A  proper  replacement  card  is  finally  located  and  installed, 
restoring  the  multiplex  to  service. 

Testing  verifies  that  Digroup  7-B  is  now  operating  properly. 
A  restoral  of  service  message  Is  sent  to  ACOC. 

AUTOVON  control  is  notified  that  its  circuits  have  been 
repaired. 


Event  Time 


/ 


Description 


01:33:00  AUTQVON  control  sends  trunk  group  modification  directives 

to  DON  and  FEL  directing  them  to  return  to  the  normal 
configuration. 


01:34:00 


Switch  supervisors  add  the  trunks  from  Di group  7-B 
to  the  operating  trunk  group. 


01:34:30  Switch  supervisors  cut  over  from  separated  signalling 

to  unified  signalling, 

01:35:30  Switch  supervisors  pull  the  patches  for  the  temporary 

analog  signalling  channel. 


This  completes  the  return  of  the  system  to  normal  operation. 


General  AUTQVON  Traffic  Overload  (Scenario  16)--The  AUTOVON  network  in  Europe 
experiences  a  buildup  of  traffic  due  to  military  operations.  The  traffic 
builds  uniformly  to  a  level  of  250%  of  normal  peak  busy  hour.  All  elements 
of  the  DCS  -  links,  switches,  etc.,  are  operating  properly.  The  events  which 
occur  during  this  overload  are  as  follows: 


Event  Time  Description 

00:00:00  Network  is  at  normal  peak  busy  load. 


00:30:00  Military  operations  commence  with  command  and  control 

notifications.  This  raises  the  traffic  level  to  115%. 
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Event  Time 

00:45:00 

00:46:00 

01:00:00 

01:30:00 

01:45:00 

02:00:00 


Description 

Full  administrative  and  command  and  control  operations 
drive  the  network  to  150%  loading.  Several  trunk  groups 
pass  their  overload  threshold,  causing  a  traffic  alarm 
at  the  AUTOVON  controller's  position. 

AUTOVON  controller  directs  all  switches  to  go  to  primary 
routing  only  for  traffic  below  FLASH  precedence.  This 
is  mechanized  via  a  text  message  to  the  switch  supervisors. 

Pyramiding  of  communications  requirements  subsequent  to 
conmand  and  control  operations  push  the  network  load  to 
250%  of  normal  peak  busy  hour. 

Increased  military  operations  are  in  full  execution. 
Communications  requirements  begin  to  return  to  normal. 

Network  load  is  now  175%  of  peak  busy  hour. 

Communications  requirements  are  down  to  120%  of  peak 
busy  hour.  AUTOVON  controller  directs  a  return  to  full 
alternate  routing  capability  via  a  text  message. 

Network  returns  to  normal.  Traffic  load  is  below  normal 
busy  hour  and  will  remain  there. 
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2.6  SUMMARY 

This  section  has  described  the  recommended  approach  to  integrate  the  sub¬ 
systems  of  the  1985  DCS  to  provide  data  supporting  real  time  System 
Control  at  the  theatre  level. 

The  changes  to  equipment  are  summarized  In  Table  2-3  .  New  equipment 
required  is  summarized  in  Table  2-4.  Section  III  discusses  the  tradeoffs 
made  in  recommending  this  system  and  additional  details  of  the  Implementation. 


TABLE  2-3  .  CHANGES  REQUIRED  IN  DCS  SUBSYSTEMS 
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SECTION  III 
DESIGN  RATIONALE 

i  » 

3.0  INTRODUCTION 

This  section  discusses  the  design  rationale  for  the  recommended  system 
described  in  Section  II.  The  following  subjects  are  discussed: 

o  Subsystem  interfaces  including  those  to  the  TTC-39  and  SB-3865,  as 
well  as  telemetry  of  this  data  to  ACOC,  and  that  between  the  DSCS 
Terminal  Control  Processor  (TCP)  and  ATEC. 

o  The  analysis  of  the  adequacy  of  ATEC  to  handle  additional  telemetry 
requirements. 

o  The  integration  of  the  DSCS  OCE  function  into  the  Network  Connectivity 
Control  function  at  ACOC,  and  the  communication  path  between  the  NCE 
and  OCE/ACOC. 

o  The  recommendation  of  using  a  AUTODIN  II  subnetwork  Control  Center 
(SNCC)  in  Europe  and  how  this  will  work. 

o  The  data  bases  required  at  ACOC  to  support  the  recommended  system. 

3.1  SUBSYSTEM  INTERFACES 

This  section  discusses  the  methods  of  acquiring  and  telemetering  data  from 
the  DCS  subsystems.  Referring  to  Figure  3-1,  the  information  flow  diagram, 
the  new  interfaces  which  must  be  established  are: 

9),  TTC-39  to  ACOC 

10),  SB-3865  to  ATEC  Communications  Interface  Set  (CIS) 
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12),  Terminal  Control  Processor  (TCP)  to  CIS 

All  of  the  other  interfaces  are  alreacty  planned  for  the  equipment  involved. 

The  guidelines  followed  in  selecting  an  implementation  for  the  subsystem 
interface  were: 

o  Minimize  changes  to  equipment 

o  Select  the  simplest  approach,  e.g.,  the  one  with  the  least  added 
equipment  or  one  using  existing  capabilities 

o  All  else  being  equal,  select  the  most  fault  tolerant  approach 

The  alternatives  considered  and  the  reasons  for  selecting  the  recommended 
approach  are  discussed  in  the  following  paragraphs. 

3.1.1  TTC-39  SYSCON  Channel  Acquisition 

As  designed  for  use  in  TRI-TAC,  the  TTC-39  multiplexes  the  SYSCON  channel 
into  the  primary  overhead  channel  of  a  TRI-TAC  transmission  group.  See 
Figure  3-2.  In  TRI-TAC,  the  multiplex  group  would  , enter  a  communications 
Network  Control  Element  (NCE)  where  it  could  pass  through  the  Channel 
Reconfiguration  Function  (CRF).  The  CRF  would  permit  the  dropping  and 
Inserting  of  any  subchannel  so  that  It  could  be  routed  to  a  processor. 
However,  in  the  DCS  there  Is  no  equipment  currently  available  which  will 
drop  or  insert  the  subchannel. 

The  possibilities  available  for  the  DCS  Include: 

a)  modifying  the  TTC-39  to  provide  a  new  I/O  port  for  the  purpose 
of  transmitting  reports  and  receiving  directions. 
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b)  Employing  a  technique  similar  to  that  in  TRI-TAC. 

If  method  (a)  is  used,  two  options  are  available  to  implement 
data  flow  to  and  from  ACOC.  The  first  is  to  use  a  direct  connection 
(dedicated  circuit)  from  each  switch  to  ACOC.  The  second  option  is  to 
interface  the  TTC-39  SYSCON  channel  output  to  the  collocated  ATEC  subsystem 
and  route  the  data  through  the  ATEC  telemetry  to  ACOC.  ATEC  offers  two 
possible  interfaces:  to  the  CIS  through  a  150  baud  asynchronous  port 
or  to  a  collocated  ATEC  NCS  using  one  of  the  SYSCON  channels  available 
at  the  Node  processor  (2400  baud). 

If  method  (b)  is  selected,  the  routing  options  for  getting  the  SYSCON 
data  to  and  from  ACOC  are  similar.  If  the  SYSCON  channel  is  extracted  at 
the  station  where  the  TTC-39  is  located,  then  either  a  direct  circuit  or 
interface  with  the  ATEC  subsystems  can  be  considered.  One  additional 
option  presents  itself  in  this  method:  select  a  centralized  switch  to 
which  all  of  the  SYSCON  channels  can  be  routed  using  the  inherent  capabiliti 
available  in  the  TTC-39  for  SYSCON  channel  routing.  In  this  latter  method, 
the  SYSCON  channels  would  be  accessed  external  to  the  TTC-39' s,  all  at  a 
single  site,  routed  to  a  single  data  concentrator  and  then  forwarded  to 
ACOC  on  a  single  channel  or  thorugh  the  ATEC  telemetry. 

The  following  two  subsections  examine  the  alternatives  in  the  areas  of 
channel  acquisition  and  channel  routing  respectively. 

SYSCON  Channel  Acquisition 


The  most  straight  forward,  seemingly  less  complex,  method  of  channel 


* 


acquisition  is  to  modify  the  TTC-39  to  provide  a  SYSCON  channel  I/O  port. 
This  can  be  accomplished  by  using  the  existing  hardware  in  the  TTC-39. 

The  modifications  would  be  in  the  area  of  the  SYSCON  Signalling  Buffer 
where  its  output  would  be  directed  to  a  new  I/O  port  rather  than  to  the 
Trunk  Signalling  Buffer.  Since  the  SYSCON  Signalling  Buffer  is  a  micro¬ 
processor  based  device  including  Memory,  I/O  Interface,  and  Central 
Processor  Group  (CPG)  Interface,  the  hardware  in  place  can  be  used  to 
accomplish  the  modifications  without  new  hardware  development  and  purchases. 
In  addition  to  routing  the  output  to  a  new  I/O  port,  the  microprocessor 
software  can  be  modified  to  accommodate  any  line  protocol  and  the  I/O 
interface  (which  consists  of  a  universal  synchronous/asynchronous  receiver 
transmitter  (USART),  timing  and  control)  can  be  modified  to  provide  a  new 
output  data  rate  if  one  different  thatn  2Kbps  is  desired. 

The  method  of  extracting  the  SYSCON  channel  external  to  the  TTC-39  could 
be  performed  by  a  Channel  Reconfiguration  Unit  (CRU).  This  unit  will 
perform  the  same  function  as  the  CRF  does  for  both  TRI-TAC  and  T1  channels. 
Feasibility  demonstration  models  will  be  developed  under  an  RADC  contract. 
(See  Reference  27) 

This  unit  performs  not  only  the  SYSCON  channel  drop  and  insert  function  (for 
a  number  of  groups)  but  also  the  function  of  reassigning  traffic  channels 
between  a  number  of  groups.  This  added  capability  is  used  to  speed  service 
restoral  in  the  event  of  outages.  When  the  CRU  is  deployed  in  the  DCS, 
the  SYSCON  channel  breakout  will  be  available. 

If  the  Interface  is  required  before  the  CRM  is  deployed,  one  possibility  is 
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to  develop  a  unit  which  performs  only  the  drop  and  insert  function  on 
individual  interswitch  trunks.  Figure  3-3  illustrates  the  functional 
components  required. 

The  recommended  approach  to  obtaining  the  TTC-39  SYSCON  channel  is  to 
extract  the  SYSCON  channel  external  to  the  TTC-39.  This  recommendation 
is  made  primarily  due  to  the  impact  of  requiring  a  change  to  a  system 
already  under  development  and  near  completion. 

SYSCON  Channel  Routing 

Four  alternatives  exist  for  routing  the  SYSCON  channels  to  ACOC.  They  are 
summarized  in  Table  3-1.  The  first  alternative  is  routing  of  the  SYSCON 
channels  from  each  switch  to  ACOC,  depicted  by  Figure  3-4.  The  figure 
shows  a  SYSCON  channel  acquisition  unit,  a  data  rate  conversion  interface 
unit,  a  modem  or  TDM  interface  at  each  switch,  a  dedicated  circuit  to  ACOC 
and  a  corresponding  modem  or  TDM  interface  and  ACOC  communication  interface 
hardware  and  software.  Format  conversion  is  integrated  into  the  ACOC 
processor  and  therefore  none  is  called  out  in  Table  3-1. 

Figure  3-5  shows  the  second  alternative  where  the  extracted  SYSCON  channel 
is  interfaced  with  collocated  ATEC  subsystems.  The  figure  shown  a  SYSCON 
Channel  Acquisition  Unit  and  data  rate  and  format  conversion  unit  at  each 
TTC-39.  The  ICD-004  protocol/format  is  converted  to  ATEC  compatible  format 
and  protocol.  Data  rates  would  be  converted  to  150  baud  asynchronous  for 
interface  to  the  CIS  and  to  2400  baud  synchronous  to  the  NCS  system  port. 

In  this  case,  each  node  routes  the  data  to  its  sector,  and  from  there  to 
ACOC. 
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SYSCON  CHANNEL  TO 


TABLE  3-1.  CHARACTERISTICS  OF  ALTERNATIVE  SYSCON  CHANNEL  ROUTING 


TTC-39/ 

ACOC  INTERFACE 
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dedicated  circuit. 

9 

2)  Reporting  through 
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central  site, 
report  on  ded. 
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Uses  SYSCON  ports  of  the  ATEC  equipment. 
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Figure  3-5.  TTC-39  SYSCON  Channel  Interface  Through  ATEC 
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Figure  3-6  shows  the  third  and  fourth  alternatives  where  all  TTC-39  SYSCON 
channels  appear  at  a  single  TTC-39  site.  This  alternative  takes  advantage 
of  the  capabilities  to  route  the  SYSCON  channel  through  an  intermediate 
TTC-39  if  all  TTC-39* s  do  not  have  a  DT6  homed  on  the  selected  TTC-39 
site.  As  the  figure  shows,  all  SYSCON  channels  acquired  at  the  one  site 
are  combined  through  a  single  computer  based  data  concentrator  for  transmission 
on  a  single  circuit  to  ACOC.  This  single  channel  can  be  routed  through 
a  dedicated  circuit  (alternative  three)  or  through  ATEC  (alternative  four). 

A  single  2400  bps  channel  is  capable  of  handling  even  the  worst  case  report¬ 
ing  load  from  all  nine  TTC-39's,  since  the  average  load  from  each  switch  is 
less  than  the  10  bps.  However,  if  alternative  four  is  used,  a  dedicated 
SYSCON  port  between  the  Sector  and  ACOC  must  be  used,  since  the  load  cannot 
be  handled  by  the  AUTODIN  interface  to  ACOC. 

Table  3-1  shows  that  alternatives  three  and  four  require  the  least  additional 
equipment.  Alternative  four  introduces  the  data  into  the  ATEC  system,  which 
would  permit  correlation  of  AUTODIN  alarms  plate  to  the  transmission  system 
and  the  ATEC  indicated  status  of  the  transmission  system.  Section  2.3 
discussed  reasons  why  this  was  not  recommended. 

From  an  implementation  viewpoint,  the  fact  that  one  alternative  would  route 
the  data  into  the  ATEC  system  suggested  re-evaluating  the  use  of  ATEC  to 
correlate  the  data.  The  negative  aspect  of  doing  this  is  that  most  of  the 
data  routed  to  ACOC  is  not  of  interest  to  ATEC.  Therefore,  ATEC  would 
process  many  messages  not  Intended  for  it  in  order  to  identify  whether  or 
not  it  was  Interested.  Even  the  data  which  ATEC  is  interested  in  will 
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ACOC 


Figure  3-6.  TTC-39  SYSCON  Channels  Routed  to  Central  Location 


ultimately  have  to  be  sent  to  ACOC  because  complete  status  of  the  AUTOVON 
system  at  ACOC  Is  required.  At  ACOC,  sufficient  data  for  correlation  of 
AUTOVON  alarms  to  transmission  system  alarms  will  be  available.  This  Is 
true  because  correlation  Is  done  only  when  a  trunk  group  Is  reported  out 
of  service,  and  In  that  case  a  high  priority  circuit  will  have  been  Impacted 
and  therefore  reported  by  ATEC  upon  detection  of  the  outage.  Thus,  the 
extra  expense  In  adding  a  correlation  In  ATEC  is  of  minimal  value.  To 
actually  route  the  data  Into  ATEC,  and  then  immediately  but  again  over  the 
SYSCON  channel  Is  not  a  reasonable  approach  since  It  causes  an  added 
load  on  ATEC  with  no  benefit.  Performing  the  report  consolidation  process 
In  the  ATEC  computer  system  was  judged  to  be  too  much  additional  function 
to  place  on  that  computer.  Therefore,  alternative  three  is  the  recommended 
approach. 

The  added  Report  Consolidation  Processor  (RCP)  must  satisfy  the  interface 
protocols  of  the  TTC-39  SYSCON  channels  (as  specified  by  ICD-004).  In 
order  to  minimize  the  bit  rate  to  ACOC,  the  RCP  will  remove  the  idle 
characters  from  the  SYSCON  channels.  It  will  then  forward  the  data  to 
ACOC.  It  will  also  accept  data  from  ACOC  and  pass  it  down  to  the  addressed 
TTC-39.  The  protocol  selection  for  the  2400  bps  synchronous  interface  to 
ACOC  is  discussed  in  the  next  section. 

Recommended  Protocol— The  line  protocol  for  dedicated  synchronous  lines 
may  be  either  bit  or  byte  oriented,  since  this  is  a  processor-to-processor 
path,  rather  than  a  terminal  to  processor  path.  The  candidate  protocols 
considered  were  the  ATEC  protocol  (byte  oriented)  or  the  ADCCP  (Advanced 
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Oata  Communications  Control  Procedures )»  ANSI  X3534/589,  which  is  planned 
for  use  In  both  AUTODIN  II  and  the  DSCS  Control  Segment. 

ADCCP  has  achieved  acceptance  by  the  United  States  government  and  the 
International  Standard  Organization  (ISO)  in  addition  to  the  American 
National  Standards  Institute. 

Commercial  equipment  supporting  this  protocol  has  been  and  will  continue 
to  be  developed.  ADCCP  Is  Ideally  suited  to  passing  ICD-004  messages. 

This  Is  a  result  of  the  transparency  provided  by  the  bit  oriented  message 
field.  Because  of  Its  commonality  and  commercial  acceptance.  It  is 
the  recommended  protocol  for  the  RCP/ACOC  Interface. 

3.1.2  SB-3865  Interface 

The  SB- 3865  is  not  currently  planned  to  have  an  interface  for  remote 
reporting  of  status  data.  It  Is  planned  to  present  the  data  to  the  attendant/ 
operator  via  status  and  alarm  displays  and  the  attendant  interface  device. 
There  are  two  areas  of  alternatives  to  consider  in  order  to  provide 
remote  reporting  capabilities: 

1.  The  formatting  of  the  report. 

2.  How  to  telemeter  the  report. 

From  some  points  of  view,  the  most  desirable  method  for  formatting  of  the 
report  Is  to  use  the  formats  of  ICD-004  (reference  15).  This  will  permit 
the  same  message  analysis  of  software  to  be  used  at  ACOC  for  both  TTC-39 
and  SB- 3865  messages.  An  additional  commonality  could  occur  in  the  soft¬ 
ware  used  to  handle  SYSCON  channel  protocols.  This  occurs  at  the  computer 
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at  Langerkopf  for  the  TTC-39's.  However,  the  use  of  the  CIS’s  as  the  entry 
points  for  the  SB-3865  data,  discussed  In  the  next  section,  requires  handling 
the  protocol  at  the  SB-3865/CIS  interface.  Thus,  the  processor  for  the 
TTC-39's  cannot  be  reused  for  the  SB-3865' s. 

Another  alternative  Is  to  use  a  reporting  protocol  for  the  messages  from 
the  SB-3865  different  than  ICD-004.  If  the  information  required  could  be 
limited  to  a  sufficiently  small  amount,  this  would  be  a  useful  method. 

For  example,  if  only  the  status  parameters  were  reported,  this  could  be 
used.  In  fact,  direct  acquisition  of  the  status  by  connecting  the  status/ 
alarm  Indicators  into  an  ATEC  Alarm  Reporting  Subsystem  could  be  employed. 

To  remotely  report  all  of  the  data  already  collected  by  the  SB- 3865,  the 
full  ICD-004  messages  are  preferable. 

The  methods  of  telemetry  for  SB- 3865  data  considered  include: 
o  Dedicated  channel  directly  to  ACOC. 

o  Use  of  subchannel  to  telemeter  data  to  a  TTC-39,  at  which  point  the 
data  will  be  entered  Into  the  ATEC  system. 

o  Telemetering  data  directly  into  an  ATEC  node  via  a  dedicated  channel. 

o  Entering  data  into  an  ATEC  CIS  port. 

Use  of  the  CIS  port  was  selected.  Discussion  of  these  methods  follows. 

The  use  of  a  dedicated  channel  to  ACOC  for  each  SB-3865  was  rejected  on 
several  bases.  First;  there  will  be  some  50  SB-3865's  in  Europe.  Therefore, 
an  excessive  number  of  circuits  would  be  required.  In  addition,  the  data 
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flow  would  be  relatively  bursty,  the  long  term  average  rate  being  about 
9  bps.  Therefore,  a  message  switching  arrangement  offers  advantages. 

Finally,  having  some  50  interfaces  at  ACOC  Is  unwieldy. 

The  use  of  the  subchannels  to  the  TTC-39  Is  not  supported  by  current  con¬ 
figurations  of  the  TTC-39  or  the  SB- 3865.  The  TTC-39  does  not  expect  to 
receive  subchannels  from  access  trunks,  which  Is  the  method  used  to  inter¬ 
face  the  SB-3865  to  the  TTC-39.  Instead,  in  band  signalling  is  used.  If 
the  TTC-39  were  modified  to  accept  such  channels,  a  large  number  of  them 
would  need  to  be  interfaced;  up  to  30  at  Donnersberg,  if  all  of  the  SB-3865's 
homed  there  were  accepted.  These  would  then  be  aggregated  together  into  a 
single  group  to  send  to  ACOC.  However,  the  TTC-39  has  no  capability  to 
multiplex  this  large  number  of  subchannels  together.  For  these  reasons, 
the  interface  should  not  be  made  to  the  TTC-39. 

The  use  of  the  Node  as  an  entry  point  requires  a  number  of  SYSCON  inter¬ 
faces  at  the  node  possibly  greater  than  defined  by  the  ATEC  10000  specification. 
A  total  of  three  SYSCON  ports  and  seven  spare  ports  are  required.  Certain 
central  Germany  nodes  could  have  more  than  that  number  of  SB-3865's.  Also, 
a  DCS  circuit  from  the  SB-3865  site  to  the  Nodal  site  would  be  required. 

The  alternative  of  sending  the  data  into  a  CIS  is  attractive  because  it  is 

i 

|  expected  that  a  CIS  will  be  at  the  SB-3865  site.  Because  the  CIS  has  150  bps 

'  !  ports  available,  it  would  be  desirable  to  use  this  rate  as  an  output  from 

i  the  SB-3865.  Since  the  SB-3865  must  be  modified  to  send  or  receive  data, 

I  i 

the  requirement  to  do  so  at  150  bps  can  be  added.  Since  the  long  term 
average  rate,  as  discussed  in  the  parameter  analysis  section,  is  about 
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9  bps.  this  would  be  a  satisfactory  rate. 

The  selected  approach  Is,  then,  to  use  a  CIS  port  for  accepting  data  from 
(and  eventually  sending  data  to)  the  SB-3865.  The  selected  approach  is 
to  modify  the  SB-3865  to  provide  a  direct  interface  at  150  bps.  To  retain 
commonality  with  the  TTC-42,  ICD-004  formatted  messages  will  be  used.  The 
alternatives  of  requiring  the  SB-3865  to  fit  the  message  into  ATEC  format 
or  using  an  external  unit  were  considered.  The  external  unit  was  selected 
to  minimize  impact  on  the  SB-3865. 

The  conversion  from  the  ICD-004  format  to  ATEC  message  format  is  complicated 
by  the  use  of  an  ASCII  character  oriented  protocol  in  ATEC  (seven  bits  plus 
parity).  ICD-004  messages,  on  the  other  hand,  use  eight  bits  plus  parity, 
and  free  form  within  the  eight  bits.  Because  no  processing  of  the  TTC-39 
data  is  planned  below  ACOC,  it  is  intended  that  the  ICD-004  message  format 
be  retained  between  ACOC  and  the  TTC-39.  The  approach  to  accommodate  this 
is  to  define  an  ATEC  message  type  which  passes  the  ICD-004  formatted 
message  within  the  ATEC  message  field. 

In  order  to  pass  the  non-ASCII  characters  through  the  message  field,  two 
approaches  have  been  identified.  The  first  is  to  pack  six  bits  of  the 
ICD-004  message  into  each  ASCII  character.  The  seventh  bit  will  always  be 
a  one,  so  that  no  control  characters  will  be  generated  by  the  reformatting. 
This  allows  the  messages  to  flow  through  without  special  processing  in 
ATEC.  There  will  always  be  216  bits  in  the  ICD-004  message,  requiring 
216  +  6  ■  36  characters. 
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Alternatively,  processing  of  parity  and  control  characters  could  be 
inhibited  in  the  message  field,  and  the  216  bits  could  be  sent  as  a 
consecutive  string  in  216  *  8  =  27  characters.  However,  this  requires 
special  handling  .via  establishing  a  message  type  telling  software  to 
ignore  parity  and  control  characters.  Therefore,  the  first  method 
discussed  was  selected.  Figure  3-7  summarizes  the  recommended  approach. 

3.1.3  TCP/CIS  Interface 

The  TCP  is  not  completely  specified  at  this  time.  The  developers  of  the 
Control  Segment  anticipated  that  a  150  bps  Port  will  be  connected  to  the 
terrestrial  DCS  to  permit  reporting  of  status  and  coordination.  It  is 
recommended  that  this  be  connected  into  the  ATEC  computer  system  at  a  CIS 
port.  This  port  was  selected  because,  a)  The  150  bps  rate  of  the  CIS 

port  is  consistent  with  the  TCP  plans,  and  b)  It  is  expected  that  there 

will  typically  be  an  MAS  system  including  ACIS  at  the  DCS  station  where  the 
satellite  and  terrestrial  system  interface,  minimizing  the  150  bps  circuit 
to  an  intra-building  connection  in  most  instances. 

Since  the  ATEC  equipment  will  be  developed  ahead  of  the  TCP,  it  is 
recommended  that  the  TCP  be  specified  for  compatibility  at  this  interface. 
The  interface  specification  for  ATEC  is  a  byte  oriented  protocol  defined 
for  the  ATEC  application.  The  message  formats  are  shown  in  Figure  3-8 

and  the  transmit  and  receive  protocols  specified  by  the  ATEC  10000 

specification  are  shown  in  Figures  3-9  and  3-10. 
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Figure  3-9.  Standard  Protocol  Transmit  Processl 


3.2  UPWARDS  COMMUNICATION  FLOW  IMPLEMENTATION 

The  reconmendatl ons  for  Implementing  the  physical  communication  flow  for 
upwards  reporting  of  status  and  performance  data  is  based  on  the  results 
of  the  communi cations  flow  analysis.  This  analysis  examined  each  system 
involved,  characterizing  the  existing  and/or  planned  command  and  control 
communication  capacity  and  budgets,  and  looked  at  intersystem  communication 
interfaces  to  augment  data  flow  to  the  Theatre/ACOC  level.  For  those 
systems  that  do  not  have  upwards  reporting  command  and  control  capabilities, 
alternatives  were  addressed.  The  ATEC  system  deployment  and  capacity/ 
budget  is  examined  for  supporting  additional  telemetry  of  SYSCON  data. 

3.2.1  Information  Flow  Requirements 

The  information  flow  requirements  based  on  the  subsystem  characterization 
and  parameter  analysis  (See  Section  V)  are  summarized  in  Table  3-2. 

This  table  shows  that  the  average  communication  loading  is  quite  low; 
even  the  worst  case  values  do  not  require  significant  communication 
capabilities. 

The  existing  command  and  control  communications  systems  are  depicted  in 
Figure  3-11.  A  portion  of  this  figure  shows  the  AUTODIN  II  reporting 
structure.  This  intra-network  interface  is  accomplished  using  the  Mode  VI 
Binary  interface  with  a  choice  of  baud  rates  (75  x  2n,  n  =  0,8,  and  56  Kbps) 
available  in  the  network.  19.2  KBPS  was  chosen  as  the  NCC  access  line  rate 
Estimates  (pp.  3-17  of  Reference  7)  showed  an  average  peak  hour  traffic  V 
load  (receive  direction)  of  approximately  6.5  Kbps,  hence,  the  selection 
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of  19.2  provides  a  peak  load  capability  considerably  above  the  hourly 
average.  The  data  transfer  protocol  for  this  interface  will  be  In 
accordance  with  the  American  National  Standard  for  Advanced  Data 
Communication  Control  Procedures  (ADCCP)  -  Independent  Numbering, 

American  National  Standard  Institute.  Our  estimate  of  26.7  bps  worst 
case  loading  between  the  SNCC  and  the  Theatre  can  be  accomplished  with 
any  selection  of  available  baud  rates. 

Also  shown  is  the  DSCS  hierarchy  Interconnections.  Planned  to  be  available 
for  this  command  and  control  interface  is  2.4,  4.8,  and  9.6  Kbps  via  AUTODIN 
or  dedicated  circuits.  A  SYSCON  channel  is  available  at  the  TCE  to  inter¬ 
face  with  the  DCS  TCF  using  asynchronous  data  at  150  baud.  The  average 
loading  for  SYSCON  data  reporting  is  negligible  and  no  burden  is  placed  on 
this  interface. 

The  deployment  of  the  AN/TTC-39  switches  in  the  DCS  does  not  provide 
access  to  the  2/4  Kbps  SYSCON  subchannel.  Similarly,  no  provisions  have 
been  made  to  automatically  receive  status  from  the  SB-3865  Telephone 
Switchboard.  Thus,  changes  are  required  to  collect  this  data.  They  are 
discussed  in  Section  IV. 

The  ATEC  reporting  hierarchy  is  also  shown  in  the  figure.  At  the  station 
level  the  Measurement  Acquisition  Subsystem  (MAS)  reports  on  150  baud 
asynchronous  full  duplex,  character  oriented  interfaces  to  the  Communication 
Interface  Set  (CIS).  The  CIS  reports  to  the  Nodal  Control  Subsystem  (NCS) 
using  2400  bps  synchronous  transmission.  The  SCS  interface  to  the  Theatre 
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level  is  by  AUTODIN.  The  AUTODIN  interface  will  be  a  full  duplex  digital 
data  circuit  operating  at  a  rate  of  2400  baud  synchronous  format  and 
protocol  as  specified  In  DCA  370  -  D175-1.  The  inter  ATEC  formats  and 
protocol  are  defined  in  ATEC  10000,  System  Specification  for  Automated 
Technical  Control,  Volume  I.  Because  of  the  wide  deployment  of  ATEC 
subsystems  (see  Figure  3-12  which  shows  the  1982-1985  European  ATEC 
Deployment  Model)  it  becomes  a  prime  candidate  to  support  the  command  and 
control  telemetry  from  other  systems,  particulary  the  AN/TTC-39  and 
SB- 3865.  Because  of  this  possibility,  a  more  detailed  examination  of 
the  subsystem  interface  telemetry  was  made  to  ensure  that  additional 
loading  was  within  the  capacity  of  the  planned  interfaces. 

3.2.2  ATEC  Telemetry  Analysis 

A  typical  ATEC  implemented  station  might  be  implemented  with  the  ensemble 
of  equipment  shown  in  Table  3-3.  It  shows  six  subsystems,  all  of  which 
provide  on- occurrence  status  reports  on  the  monitored  communication  system. 
References  for  the  reporting  frequency  and  message  length  are  the  ATEC  10000 
Specification  and  the  associated  Appendices.  The  composite  load  from  a 
single  CIS,  configured  in  the  manner  described,  is  22  bps  over  a  15  minute 
interval.  This  is  described  as  being  the  normal  operating  environment. 

In  the  deployment  model,  the  SGT  Sector  and  the  SGT  node  have  the  most 
nodes  and  subordinate  stations  respectively.  A  closer  look  at  the  possible 
loads  due  to  the  MAS  elements  and  some  assumptions  concerning  the  other 
uses  of  the  telemetry  system  are  In  order  based  on  those  loads.  The  SGT 
Node  has  the  most  stations  reporting  to  it  and  the  deployment  model  for  that 
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Figure  3-12.  European  ATEC  Deployment  Hierarchy  (1982-1985! 


TABLE  3-3.  TYPICAL  ATEC  STATION  DEPLOYMENT 


FAULT  REPORTING  TO  CIS 


MAS  ELEMENT 

NO. 

REPORTS  IN 

15  MIN. 

MSG.  LENGTH 
(CHAR.) 

TOTAL 

CHAR. 

IMS 

1 

10 

40 

400 

DMS 

1 

10 

40 

400 

BTS 

1 

5 

50 

250 

WDS 

1 

5 

122 

610 

ARS 

1 

1 

17 

17 

PCS 

1 

_1 

20 

_ 20 

32 

1697 

ATEC  PROTOCOL 

HEADER  +  TRAILER  =21+2 

=  23  CHARS. 

32  MSGS  x  23  = 

736 

2433 

AT  8  BITS/CHAR  -  = 

19464  BITS 

15  MIN 

900  SEC. 

19464 


22  BPS 
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node  is  shown  in  Figure  3-13.  This  shown  a  total  of  15  CIS's  where  7 
are  connected  directly  to  the  node  and  9  are  polled  by  a  CIS.  Drawing 
from  the  ATEC  10000  Specification  a  node  shall  continue  to  function 
properly  under  a  sustained  load  of  1200  bps  from  each  of  up  to  eight 
subordinate  CIS's  and  traffic  distribution  shall  be  as  follows: 

o  30%  Exception  Reports  from  MAS  elements 

o  20%  Routine  Performance  Data 

o  40%  Responses  to  Inquiries 

o  10%  Message  Mode  Traffic 

Therefore,  the  maximum  sustained  loading  condition  of  360  bps  would 
be  associated  with  exception  reports.  The  normal  load  from  three  CIS's 
(two  polled  and  one  directly  connected) >assuming  each  reporting  22  bps 
over  the  same  telemetry  link  to  the  node, is  (22  x  3)  =  66  bps.  This  is 
a  ratio  of  66/360  or  '19%  from  normal  to  maximum  sustained  loading.  Assum¬ 
ing  that  this  same  ratio  or  performance  applies  to  all  traffic,  then  the 
normal  loading  on  any  ATEC  telemetry  to  the  NCS  is  19%  of  1200  bps  or 
approximately  230  bps.  If  the  assumptions  are  valid,  then  ATEC  telemetry 
links  do  offer  reserve  capacity  to  handle  additional  telemetry  from 
collocated  or  adjacent  systems  for  the  purpose  of  upwards  status  reporting. 
With  each  of  the  station  CIS/MAS  elements  ensembles  reporting  32  messages 
in  15  minutes,  there  is  a  composite  load  of  480  messages  in  15  minutes  at 
the  S6T  Node  due  to  MAS  element  exception  reports. 


i 


Figure  3-14  shows  four  NCS  reporting  to  the  SGT  sector.  A  similar  analysis 
for  each  node  yields  the  message  load  from  the  subordinate  stations  as 
shown.  To  estimate  the  loading  at  the  sector  due  to  exception  reports, 
the  following  assumptions  were  made  concerning  the  disposition  of  exception 
reports  at  the  nodes: 

o  70%  of  the  exception  reports  (ER)  are  old  or  previously  reported 
fault  conditions. 

o  20%  of  the  ER's  are  correlated  with  other  faults. 

o  5%  of  the  ER's  indicate  fault  isolated  or  fault  cleared  conditions 
to  be  passed  on  to  the  Sector. 

o  5%  of  the  ER's  produce  a  fault  transfer  message  to  the  Sector. 

Using  the  above  assumptions,  the  message  load  at  the  SGT  node  produces 
48  messages  in  15  minutes  to  SGT  Sector  and  the  composite  load  from  all 
nodes  subordinate  to  the  SGT  Sector  is  152  messages  in  15  minutes.  The 
heaviest  load  of  48  messages  assuming  100  characters  per  message  (including 
overhead)  is  43  bps. 

The  disposition  of  the  fault  reports  and  fault  transfers  at  the  Sector 
is  assumed  to  be  as  follows: 

o  50%  of  the  messages  are  concerned  with  fault  isolations  and  as 
such  are  reported  to  the  Theatre. 

o  40%  are  correlated  (or  80%  of  all  fault  transfers  are  correlated 
with  other  faults). 
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o  10%  result  in  fault  isolation  reports  to  the  Theatre  (20%  of  all 
fault  transfer  messages). 

This  results  in  a  total  of  91  fault  reports  being  sent  to  the  Theatre  in 
a  15  minute  period  or  a  loading  of  approximately  80  bps  from  the  SGT 
sector. 

Applying  the  same  rationale.  Figure  3-15  shows  the  approximate  composite 
load  at  the  Theatre  due  to  the  performance  assessments  and  fault  isolation 
process  in  ATEC.  The  telemetry  loading  from  the  station  to  the  NCS  was 
assumed  to  be  30%  due  to  the  exception  reports  and  70%  for  other  traffic. 

The  loading  from  the  NCS  to  the  SCS  is  assumed  to  be  20%  for  fault  reporting 
and  fault  transfers  and  80%  for  other  traffic.  Between  the  SCS  and  AC0C, 
the  total  traffic  load  associated  with  fault  reporting  is  10%. 

Several  conclusions  can  be  derived  from  this  analysis.  First,  there  is 
sufficient  excess  telemetry  budget  to  support  both  the  SB-3865  (average 
reporting  load  =  3.8  bps)  and  AN/TTC-39  (average  reporting  load  =  8.8  bps) 
status  and  performance  assessment  reporting  load.  The  composite  average 
load  due  to  nine  TTC-39's  is  80  bps  or  the  composite  average  load  due  to 
approximately  50  SB-3865' s  is  190  bps.  Second,  if  manual  intervention  is 
required  for  each  reported  fault  to  the  next  higher  level,  then  the 
assumptions  made  in  this  analysis  are  too  pessimistic  and  the  actual 
load  due  to  fault  reporting  will  be  much  less.  (Assuming  one  CRT  terminal 
devoted  exclusively  to  the  reporting  function,  the  call-up,  review,  editing 
approval,  and  send  process  will  take  up  to  one  minute  per  message.)  Thus, 
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Figure  3-15.  ACOC  Loading 
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the  ATEC  system  would  have  even  greater  excess  capacity  to  serve  other  users. 

3.2.3  Recommended  Communications  Flows 

The  recommended  communications  flows  which  were  presented  in  the  beginning 
of  this  section  are  summarized  below.  The  AUTODIN  II  SNCC,  DSCS  NCE,  and 
ATEC  Sector  report  to  ACOC  using  existing  AUTODIN  access  lines.  The  TTC-39 
SYSCON  channels  are  consolidated  at  a  centralized  point  and  are  routed  to 
ACOC  on  a  dedicated  circuit.  The  SB-3865  reports  are  interfaced  through 
the  ATEC-CIS  and  ride  the  ATEC  telemetry  network  arriving  at  ACOC  via  AUTODIN 
from  the  ATEC  Sector. 

3.3  PERFORMANCE  OF  OCE  FUNCTIONS  USING  THE  REAL-TIME  AOC  COMPUTER 
Implementation  of  the  Control  Segment  (CS)  portion  of  DSCS  in  the  mid  1980's 
will  result  in  the  physical  relocation  of  the  day  to  day  DSCS  operations 
from  ACOC  to  the  NCE's.  The  function  remaining  at  the  area  level  will  be 
the  dynamic  management  of  DSCS  resources  such  that  they  may  be  best 
utilized  by  the  DCS  and  other  DSCS  users.  The  dynamic  management  function 
consists  of: 

o  Awareness  of  the  status  and  configuration  of  DSCS  resources. 

o  Planning  scheduled  allocation  of  resources  to  requesting  users. 

o  Filling  real  time  connectivity  requests  from  the  DCS  management 
functions. 

This  function  can  be  Implemented  on  a  dedicated  computer  facility  or  it 

/  ’ 

can  be  made  a  portion  of  the  recommended  real-time  ACOC  Computer. 
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The  recommended  approach  of  combining  It  with  WWOLS  was  agreed  to  by  the 
DCEC  personnel  planning  the  deployment  of  the  DSCS  CS. 

As  previously  stated,  OCE  functionality  can  be  divided  Into  three  portions. 
Resources  needed  to  support  each  portion  are  as  follows: 

1.  Complete  cognizance  of  all  DSCS  resources 

o  Communication  line  Interface  to  NCE  (software  and  hardware) 
o  Report/message  processor  programs 
o  DBMS  interface  programs 

o  Man-Machine  Interface  Management  software  (SW)  (display  file 
management) 

o  DBMS 

2.  Planning  scheduled  allocation  of  resources  to  requesting  users 
o  A  Man-Machine  Interface  and  supporting  SW;  using  CRT 

o  Application  SW  that  manages  resources  as  functions  of  time 

o  Application  SW  that  selects  links  as  functions  of  source, 
destination,  bandwidth.  (This  should  be  at  least  partially 
implemented  as  a  feature  of  a  DBMS.) 

o  Output  message  formatting  SW 


o  Input  message  decoding  SW 


3.  Filling  real  time  connectivity  requests  form  the  DCS  management 
functions. 

o  Man  Machine  Interface  and  supporting  SW 
o  Output  message  formatting  SW 
o  Input  message  decoding  SW 

o  Application  SW  that  selects  links  as  functions  of  source, 
destination,  bandwidth.  (This  should  be  at  least  partially 
implemented  in  a  DBMS  query  facility.) 

All  three  aspects  of  the  DSCS  dynamic  management  function  are  similar  to 
those  of  terrestrial  transmission  system  management.  Therefore,  it  is 
recommended  that  the  OCE  function  be  incorporated  directly  into  the  Net¬ 
work  Connectivity  Control  Function. 

3.3.1  NCE  to  OCE-WWOLS  Interface 

DSCS  plans  indicate  that  a  9600  baud  line  will  be  required  between  the  NCPs 
and  OCE  computers  at  DCAOC  and  ACOC.  The  NCEs  of  concern  to  the  European 
DCS  are  those  responsible  for  the  manipulation  of  the  Indian  Ocean  (10) 
and  Atlantic  (LANT)  satellites. 

These  are  located  at: 

o  Landstuhl ,  Germany 
o  Clark,  the  Phi 1 1 1  pi nes 

o  Two  CONUS  sites  (Ft.  Detrick,  Ft.  Meade  or  Northwest) 
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The  types  of  connections  under  consideration  are: 
o  Dedicated  and  direct  as  possible. 

o  Dedicated,  but  avoiding  the  satellite  which  is  the  subject  of 
the  reports  being  transmitted. 

o  AUTODIN  II. 

The  existence  of  dedicated  circuits  with  assigned  restoral  priorities  and 
preplanned  altroutes  guarantees  that  the  necessary  telemetry  paths  are 
available  when  needed. 

The  argument  in  favor  of  the  second  type  of  connection  is  simply  that  it  is 
undesirable  to  transmit  control /report  information  via  the  medium  which  shou 
should  be  controlled  or  reported  upon.  Stress  or  failure  situations,  to 
management  information  path  could  be  irrevocably  blocked  leaving  the 
satellite  subequally  unreportable  and  uncontrollable  until  connectivity 
changes  are  implemented. 

The  use  of  AUTODIN,  on  the  other  hand,  guarantees  that  all  information  to 
be  relayed  in  either  direction  will  be  transferred  by  the  most  direct 
working  path  if  system  capacity  is  available. 

AUTODIN  may  use  the  subject  satellite  if  it  is  working  and  provides  the 
most  direct  route,  or  it  can  configure  around  a  broken  (or  fully  loaded) 
satellite  path  in  favor  of  a  less  direct  but  available  route. 

The  recommended  interface  is  the  use  of  AUTODIN  to  provide  NCE  to  OCE-WWOLS 
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All  of  the  NCE's  and  both  of  the  OCE's  of  concern  to  European  System 
Control  are  convenient  to  AUTODIN.  AUTODIN  itself  will  provide  built-in 
maintenance  of  the  communication  paths  required  and  will  automatically 
control  relay  of  Information  according  to  the  AUTODIN  priority  scheme. 

3.4  LOCATION  OF  AN  AUTODIN  II  SUB  NETWORK  CONTROL  CENTER  (SNCC) 

The  three  AUTODIN  II  nodes  in  Europe  are  an  extension  of  the  CONUS  DIN  II 
network.  As  such,  it  is  intended  that  these  nodes  report  to  the  Network 
Control  Center  (NCC)  in  CONUS.  However,  the  European  ACOC  must  also  be 
congnizant  of  all  conditions  present  In  the  European  DCS.  Because  a  three 
node  network  exists  in  Europe,  the  status  of  the  European  portion  of  the 
network  should  be  available  to  ACOC  Europe.  This  permits  management  of 
the  European  Network  even  if  connection  to  CONUS  is  lost.  Also,  it  permits 
attention  to  be  focussed  on  the  European  portion  of  the  Network.  To  support 
this  requirement,  management  information  concerning  the  European  DIN  II 
nodes  can  be  made  available  to  the  European  ACOC  in  either  of  two  ways: 

1)  All  reports  from  packet  switching  nodes  (PSN's)  in  Europe  are  sent  to 
the  NCC  at  DCAOC  where  they  are  processed  and  reduced  such  that  management 
information  pertinent  to  Europe  is  then  transmitted  to  the  European  ACOC. 

2)  All  reports  from  the  PSN's  in  Europe  are  routed  to  a  Sub-Network 
Control  Center  (SNCC)  at  ACOC  in  Europe  where  they  are  used  to  support  the 
DIN  II  management  function  in  Europe.  These  reports  are  then  readdressed 
and  passed  to  the  NCC  in  CONUS  with  only  the  destination  address  modified. 
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Detailed  implementation  criteria  of  these  two  methods^  along  with 
recommendations  for  implementation  are  provide^  below. 

1)  All  reports  from  European  DIN  II  nodes  are  routed  to  the  NCC  in  CONUS. 
The  NCC  filters  the  information  it  receives  and  transmits  that  which  is 
appropriate  to  DCAOC  via  the  AUTODIN  II  network  in  the  form  of  55-1  reports. 
This  same  information  is  also  required  for  network  management  at  the  ACOC 

in  Europe  and  would  be  transferred  via  AUTODIN. 

2)  All  reports  from  European  DIN  II  nodes  are  routed  to  a  proposed  SNCC 
at  the  ACOC  facility  in  Europe.  These  reports  are  filed,  then  readdressed 
and  transmitted  to  the  NCC  in  CONUS  via  AUTODIN  where  they  are  processed 
according  to  the  system  design  spec.  The  SNCC  is  proposed  to  be  an  exact 
copy  of  the  NCC  in  both  hardware  and  software  with  the  following  exceptions: 

o  The  address  look-up  table  in  each  European  PSN  would  be  modified 
to  contain  the  SNCC  address  instead  of  the  NCC  address. 

o  The  SNCC  software  would  be  modified  such  that  is  would  readdress 
and  transmit  all  reports  received  to  the  NCC  in  CONUS. 

The  selection  of  option  two  above  is  recommended  for  the  followinq 
reasons : 

a)  The  placement  of  SNCC  in  Europe  provides  for  autonomous  monitoring 
and  control  of  European  AUTODIN  II.  Thus,  failures  of  the  CONUS 
NCC  or  loss  of  connection  to  it  doesn't  remove  European  control 
capability. 


fc)  The  placement  of  a  SNCC  In  Europe  allows  the  European  AUTODIN 
control  function  to  be  Implemented  in  an  already  defined  fashion 
on  an  already  designed  meachine  without  modifying  or  adding 
anything  to  the  ACOC  complex. 

c)  European  AUTODIN  control  will  be  identical  to  CONUS  with  respect 
to  reports  received,  displays  and  utilities  provided  and  control 
actions  available. 

d)  European  information  will  be  readily  available  to  the  control 
functions  in  Europe  without  tying  up  trans-Atl antic  communications. 
If  desirable,  the  reports  could  be  relayed  to  CONUS  at  a  lower 
priority  to  allow  more  urgent  traffic  access  to  DIN  resources. 

e)  The  information  received  by  the  European  ACOC  is  that  with  which 
it  is  concerned.  If  the  DCAOC  was  the  first  WWOLS  level  computer 
to  receive  DIN  information,  it  would  have  to  sort  out  that  which 
is  relevant  to  Europe  and  transmit  it  to  ACOC.  This  would  be 

a  change  in  the  proposed  operation  of  the  DCAOC-WWOLS  computer 
facility.  The  recommended  implementation  requires  no  changes 
to  any  of  the  WWOLS  computer  facilities. 

3.5  OPERATION  OF  THE  AUTODIN  II  SUBNETWORK  CONTROL  CENTER  (SNCC)  IN  EUROPE 
The  SNCC  will  be  an  exact  duplication  of  the  NCC  hardware  and  software  with 
one  addition  to  the  software: 

o  All  reports  received  from  the  Packet  Switching  Nodes  (PSN)  will  be 
readdressed  by  the  SNCC  and  transmitted  to  the  NCC  in  CONUS. 
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The  general  operating  scenario  for  European  AUTODIN  switches  and  management 
will  be  as  described  below. 

All  European  PSN's  will  operate  exactly  as  designed  for  CONUS  implementation. 
They  will  generate  periodic  and  exception  reports  detailing  the  operation  of 
the  network.  The  destination  address  for  these  reports  will  be  the  SNCC, 
however,  but  this  should  have  no  implication  in  the  operation  of  the  PSN. 
Reports  received  at  the  SNCC  will  be  filed  for  processing  and  then  readdressed 
and  retransmitted  to  the  NCC. 

The  report  contents  will  be  processed  by  the  SNCC  software  as  designed  and 
implemented  for  the  NCC.  This  implies  that  a  European  AUTODIN  II  Control 
Function  will  be  available  to  the  ACOC  independent  of  the  global  AUTODIN 
Control  Function  at  DCAOC.  To  this  end,  the  displays  supporting  the 
European  AUTODIN  will  be  of  the  same  format  and  hierarchy  as  defined  for  the 
NCC,  but  will  summarize  only  the  European  nodes.  Similarly,  the  control 
actions  available  to  the  control  function  will  be  the  same  as  are  available 
to  the  NCC  in  CONUS.  (It  may  be  desirable  to  limit  via  software  or  table 
contents  the  PSN's  over  which  the  European  AUTODIN  Control  Function  has 
jurisdiction..  Whether  or  not  this  requires  significant  (or  even  any)  changes 
depends  upon  the  implementation  of  the  NCC  software.  It  is -expected 
that  the  topology  of  the  network  to  be  controlled  is  built  into  the  system 
via  tables  rather  than  being  in  the  code. 
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Because  the  SNCC  will  be  an  almost  exact  copy  of  the  NCC,  the  information 
transferred  from  the  SNCC  to  the  ACOC-WWOLS  complex  will  be  of  the  same 
variety  as  that  which  is  defined  for  delivery  from  the  NCC  to  DCAOC-WWOLS. 

In  summary,  the  SNCC  will  provide  exactly  the  same  management  and  control 
functions  for  the  European  PSN's  as  the  NCC  is  to  provide  for  the  entire 
DIN  network. 

3.6  AUTOVON  DATA  BASE 

The  AUTOVON  data  base  contains  all  the  information  about  the  network's 
configuration  and  status  necessary  to  perform  theatre  level  AUTOVON 
control  functions.  This  data  is  contained  in  seven  file  types,  as  follows: 

o  Network  configuration  file 

o  Switch  equipment  status  and  history  files 

o  Switch  configuration  files 

o  Switch  traffic  files 

o  Trunk  group  status  files 

o  Trunk  group  traffic  files 

o  Critical  user  access  status  file 

The  Interrelation  of  these  files  is  shown  in  Figure  3-16.  The  overall 
size  of  the  data  base  is  38,000  bytes.  The  network  configuration  file 
(Table  3-4  )  contains  the  basic  layout  of  the  network  and  those  data  items 
which  are  common  throughout  the  network.  It  provides  the  controller  with 
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AUTOVON  Data  Base 


TABLE  3-4.  NETWORK  CONFIGURATION  FILE 


ITEM 

COMMENTS 

SIZE 

(BYTES) 

Switch  names 

Provides  correspondence  between  DCS 
station  name  and  network  logical  switch 
number.  Three  (3)  ASCII  characters 
per  switch. 

27 

Connectivity  Table 

Provides  forward  pointer  from  network 
connectivity  to  logical  trunk  group 
names.  Two  (2)  BCD  digits  for  each  end 
of  each  trunk  group. 

50 

Call  inhibit  tables 

Tables  used  by  switches  to  prevent  any 
calls  forwarded  to  certain  switch  codes. 
Used  to  implement  destination  code 
cancellation.  Thirty  (30)  NYX  tables 
of  50  NNX  entries,  BCD. 

2265 

TOTAL 

2342 

Number  of  such  records  -  1 


Total  Bytes  -  2342 
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a  quick  reference  of  the  overall  network  configuration  and,  more  importantly, 
forms  the  root  of  the  Information  tree  containing  all  the  network  information. 
From  the  network  configuration  file,  pointers  can  be  used  to  locate  any 
Information  about  the  network  and  how  it  interrelates.  The  network  con¬ 
figuration  file  also  contains  a  set  of  call  inhibit  tables.  Call  inhibit 
tables  are  used  in  each  TTC-39  switch  to  prevent  calls  to  certain  switch 
codes.  Typical  entries  on  these  tables  would  be  non-existant  switches,  or 
switches  which  are  completely  out  of  service.  Call  inhibit  tables  are  not 
subscriber  class  marks,  but  are  universally  applied  to  any  call  passing 
through  a  switch.  In  the  general  case,  each  switch  could  have  a  different 
set  of  call  inhibit  tables,  in  which  case  they  would  be  part  of  the  individual 
switch  configuration.  However,  because  of  the  way  call  inhibits  are  used 
there  will  be  a  large  amount  of  commonality  between  switches.  Therefore, 

It  is  reasonable  to  keep  the  details  of  a  set  of  call  inhibit  tables  in  a 
centralized  location  with  an  index  to  those  tables  in  the  individual  switch 
files.  Another  data  type  very  similar  to  the  call  inhibit  table  is  the 
zone  restriction  table.  The  major  difference  is  that  zone  restriction  is 
a  subscriber  classmark.  As  such,  it  would  not  normally  be  used  in  theatre 
level  control  and  it  is  therefore  excluded  from  the  theatre  data  base. 

A  switch  equipment  status  and  history  file  (Table  3-5  )  exists  for  each 
TTC-39  or  SB- 3865  switch.  The  status  information  is  required  to  keep 
the  controller  Informed  of  what  switch  resources  are  available  for  meeting 
current  communications  needs.  The  history  portion  of  the  file  is  used 
by  the  controller  to  find  out  the  normal  restoral  time  for  any  given 
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TABLE  3-5.  SWITCH  EQUIPMENT  STATUS  AND  HISTORY  FILE 


ITEM 

Status  and  history 
subrecord  for  each 
reportable  piece  of 
equipment,  containing 
the  following: 

Number  operating 

Number  stand  by 

Number  failed 


Failure  rate 


Average  restoral 
time 

Average  repair 
time 

Number  of 
accumulated 
failures;  daily, 
monthly,  yearly 

Failure  time 
integral 


COMMENTS 


Provides  indication  of  operating  resource.  1 

Provides  indication  of  reserve  resource.  1 

Provides  indication  of  currently  inoperable  1 

resource. 

Total  number  of  failures/total  operating  4 

time  required  by  310-130-2. 

Used  by  controller  to  determine  whether  or  1 

not  a  response  to  a  stress  is  appropriate. 

Same  as  restoral.  1 

Used  by  controller  to  be  aware  of  abnormal  3 


failure  problems.  Provides  controller  with 
insight  as  to  what  may  be  expected  to  fail, 
so  that  he  does  not  place  excessive  demands 
on  weak  equipment. 

Total  time  a  piece  of  equipment  has  been  6 

in  failed  state  -  provides  measure  of 

equipment  availability.  _ 

SUBTOTAL  18 
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TABLE  "3-5 .  SWITCH  EQUIPMENT  STATUS  AND  HISTORY  FILE 

(CONT) 


Reportable  Equipment: 


Power  units 

Tenley  controllers 

TTC-39  only. 

Switching  controller 

group 

Master  timing 

generator 

Trunk  signalling 

TTC-39  only. 

buffers 

Digital  receivers 

DTMF  receivers 

TTC-39  only. 

MF  receivers 

TTC-39  only. 

DTMF/MF  senders 

TTCt39  only. 

IMU 

TTC-39  only. 

LKG 

TTC-39  only. 

TOTAL  (TTC-39)  234 
(SB3865)  72 


Number  of  such  records  -  TTC-39  -  9 

SB-3865  -  45 


Total  Bytes  (9  x  234)  +  (45  x  72)  =  5346 
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failure.  If  the  normal  restoral  time  is  short,  no  other  control  action 
would  be  necessary.  The  historical  data  is  also  required  for  making 
management  threshold  decisions  as  defined  in  DCAC- 310- 130-2. 

The  switch  configuration  file  (Table  3-6)  exists  for  each  TTC-39  switch. 

It  provides  the  controller  with  a  small  subset  of  the  tables  which  control 
the  TTC-39.  It  is  used  by  the  controller  to  determine  the  routing  and 
traffic  control  procedures  currently  in  effect  at  each  switch. 

The  switch  traffic  file  (Table  3-7)  contains  the  current  values  of  those 
traffic  parameters  which  are  switch  related  (as  opposed  to  trunk  related). 
These  data  items  are  useful  for  analysing  the  characteristics  of  the 
traffic  load.  This  file  exists  for  each  TTC-39  and  SB-3865  switch. 

The  trunk  group  status  file  (Table  3-8)  contains  information  on  which 
circuits  make  up  the  trunk  group  and  what  their  operating  condition  is. 
This  file  exists  for  each  trunk  group  in  the  network,  and  is  required  to 
provide  the  controller  with  knowledge  of  the  trunk  capabilities  currently 
available  in  meeting  communications  requirements.  It  also  provides  the 
cross  reference  between  the  logical  trunk  group  name  used  the  the  TTC-39 
switches  and  the  CCSD  identifier  used  the  the  transmission  system. 

The  trunk  traffic  file  (Table  3-9)  contains  the  current  value  and  the 
history  of  traffic  parameters  which  are  related  to  trunk  groups.  These 
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TABLE  3-6-  SWITCH  CONFIGURATION  FILE 


SIZE 

ITEM  COMMENTS  (BYTES) 


Routing  Table  20  switches  80 

destination  switch  code  2  bytes 
type  routing  1  byte 

trunk  group  1  byte 

Trunk  groups  Logical  names  of  all  trunk  groups  28 

in  operations  terminating  on  this  switch. 

Call  inhibit  tables  Listing  of  which  call  inhibit  tables  20 

from  network  configuration  file  are 
in  operation  in  this  switch. 

Line  load  control  1 

status 

Satellite  control  parameter  1. 

TOTAL  130 


Number  of  such  records  -  9 


Total  Bytes  -  9  x  130  =  1170 
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TABLE  3-7.  SWITCH  TRAFFIC  FILE 


ITEM 


Calls  blocked  by 
precedence 

Dial  tone  delay 
(1  second) 

Total  switch  accesses 
Calls  completed 


COMMENTS 

Last  hours  total 

Last  hours  total 

Last  hours  total 

Last  hours  value  for  each  node 


Number  of  such  records  -  TTC-39  -  9 

SB- 3865  -  45 


Total  Bytes  -  54  x  30  =  1620 


TABLE  3-8  .  TRUNK  GROUP  STATUS  FILE 


ITEM 


COMMENTS 


SIZE 

(BYTES) 


Trunk  group  ID 
Digital  Portion  CCSD 

Transmission  rate 
Digital  error  rate 

CCSD  for  each  analog 
trunk 


Transmission  status 


Analog  signalling 
status 

Failure  reports 


Logical.  An  number  from  1-127  used  by  1 

the  TTC-39  to  identify  the  group. 

Eight  alphanumeric  identifier  used  by  8 

transmission  system  to  identify  the 
circuit  which  carries  the  TDM  digital 
group . 

Number  of  channels/speed  of  transmission  1 

of  the  digital  portion  of  the  trunk  group. 

Quality  of  digital  transmission  as  measured  1 
by  the  TTC-39's  decoded  of  the  common 
signalling  channel. 

Each  analog  trunk  is  a  seperately  400 


idetiflable  circuit  at  the  transmission 
system  interface.  There  could  be  up  to 
50  trunks  in  a  trunk  group,  each  with 
its  own  8  character  CCSD. 


For  each  circuit,  1  byte  to  indicate  51 

status  as  seen  by  the  switch  netowork, 
and  as  seen  by  the  transmission  system. 

Indicator  of  whether  signalling  is  using  1 

digital  common  channel,  or  inband. 

Last  twenty  reports  (1  crt  screen  full)  or  440 
24  hours,  whichever  is  less.  Informs 
controller  of  recent  history  of  trunk 
group.  _ 

TOTAL  903 


Number  of  such  records  -  25 

Total  Bytes  -  25  x  903  =  22575 
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TABLE  3-9.  TRUNK  TRAFFIC  FILE 


SIZE 

ITEM  COMMENTS  (BYTES) 


Current  readings  of  Details  used  to  solve  unusual  traffic  48 

all  traffic  parameters  problems. 

Filtered  values  -  Primary  parameter  for  alarming  traffic  2 

measured  call  con-  overload, 

gestion,  offered 
traffic 

Alarm  and  warning  Values  for  call  congestion  and  offered  4 

level  thresholds  traffic  which  initiate  alarms. 

Hourly  values  of  call  Used  by  controller  to  identify  demand  24 

congestions  trends,  past  24  hourly  values.  _ 


TOTAL  78 


Number  of  such  records  -  25 


Total  Bytes  -  25  x  78  =  1550 
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parameters  provide  the  controller  with  the  basic  information  regarding 
the  patterns  of  traffic  in  the  network,  which  is  required  in  order  to 
analyze  the  operational  situation  and  determine  appropriate  control 
actions. 

The  critical  user  access  status  file  (Table  3-10)  contains  the  identity  of 
all  critical  users  and  the  status  of  their  access  status.  By  monitoring 
the  access  status,  the  controller  can  be  made  aware  that  critical  sub¬ 
scriber  connectivity  is  being  maintained. 

3.7  NETWORK  CONNECTIVITY  DATA  BASE 

The  Network  Connectivity  Data  Base  permits  the  necessary  displays  to  be 
generated  within  ACOC.  This  implies  that  the  contents  include  all  of 
the  data  recommended  for  use  at  the  ACOC  for  real  time  control  functions 
and  that  the  relationships  between  system  elements  necessary  for  stress 
isolation,  impact  summaries,  and  available  resources  identification  may 
be  identified.  The  work  is  an  extension  of  that  presented  in  Reference 28. 


The  intent  has  been  to  define  the  data  base  as  If  it  is  a  part  of  one 
global  data  base.  Therefore,  any  system  element  may  be  traced  to  the 
responsible  area.  For  example,  each  circuit  file  entry  identifies  the 
station  which  is  the  facility  control  office.  The  station  file  in  turn 
Identifies  the  node,  sector,  and  ACOC  responsible  for  that  station. 
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TABLE  3-] 

ITEM 

Loop  ID 

Loop  circuit  CCSD 
Telephone  number 
Location 
Access  status 

Security  requirement 

Subscriber  instrument 
type 

Signalling  classification 


.  CRITICAL  USER  ACCESS  STATUS  FILE 


SIZE 

COMMENTS  (BYTES) 


Switch  number  and  physical  loop  number  6 

(BCD) . 

8 

3 

Physical  location  of  subcriber.  10 

Operational /non-operational  condition  h 

of  access  circuit,  terminal  equipment. 

Access  circuit  security  requirements,  h 

needed  for  rehoming. 

TA  341,  WECO  500D,  etc.,  needed  for  1 

rehomong. 

Dial  pulse,  DTMF,  etc.,  needed  for  1 

rehoming.  _ 

TOTAL  30 
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The  files  included  In  the  data  base  and  their  links  are  shown  in  Figure  3-17. 
The  links  Identified  by  "L"  are  direct  links  with  a  pointer  to  the  related 
record.  The  links  identified  by  "V"  are  virtual,  links.  This  implies  that 
the  linkage  exists  by  virtue  of  including  a  key  for  the  related  record, 
such  as  the  sector  including  the  names  of  each  node  it  is  related  to. 

The  contents  of  these  files  is  described  in  Tables  3-11  through  3-18. 

The  use  of  the  items  included  is  identified  in  the  comnents  column.  The 
sizing  of  each  item  is  described  in  Table  3-19  .  This  is  consistant  with 
the  current  DCA  data  base.  A  brief  description  of  the  overall  use  of  each 
file  type  follows. 

Sector  Fi1e--The  sector  file  identifies  the  reporting  nodes  and  the  report¬ 
ing  status  of  the  sector.  (See  Table  3-11.) 

Node  File— The  node  file  identifies  the  reporting  stations,  responsible 
sector,  and  reporting  status  of  the  node.  (See  Table  3-12.) 

Station  File— The  station  file  identifies  the  status  of  both  the  reporting 
capabilities  and  communication  capabilities  of  the  stations.  Any  outage 
associated  with  the  station  will  be  linked  to  this  file.  Note  that 
TCE's  will  be  included  as  stations  in  this  list.  (See  Table  3-13.) 

Connectivity  Path  File— The  connectivity  path  file  is  linked  to  all  links 
which  comprise  it  to  permit  assessing  the  status  of  the  total  connectivity 
path.  Because  a  large  number  of  links  may  exist  in  some  connectivity 
paths,  space  is  allocated  for  multiple  faults.  (See  Tabic  3-14.) 


Figure  3-17.  Network  Connectivity  Files  and  Links 


-TABLE  3-11.  SECTOR  FILE  CONTENTS 


Item  Comments  Bytes 

Sector  ID  3 

Node  List  (Up  to  6  Nodes)  For  operator  reference.  18 

ACOC  ID  Locates  the  sector  within  the  3 

global  data  base. 

Sector  Reporting  Status  Indicates  if  any  reports  are  1 

overdue  or  if  the  telemetry 
from  the  station  is  out  of 
service. 

Fault  Detail  Pointer  To  first  of  a  string  of  fault  6 

reports  allowing  that  fault 
report  to  be  accessed. 

CCSD  of  ATEC  Telemetry  to  ACOC  Permits  the  details  of  that  8 


telemetry  path  to  be  looked  up 
if  it  must  be  restored  or  its 
condition  is  in  question. 


39 


Number  of  Such  Records  -  5  (5  sectors/area) 
Total  Bytes  =  5  x  39  =  195 
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TABLE  3-12.  NODE  FILE  CONTENTS 


Item 


Comments 


Bytes 


Node  ID 

Responsible  Sector 

Responsible  Area 

Station  List  (Up  to  6) 

Node  Reporting  Status 

Fault  Detail  Pointer 

CCSD  of  ATEC  Telemetry  to  Sector 


3 


Locates  the  node  within  the  3 

global  data  base. 

Locates  the  node  within  the  3 

global  data  base. 

For  operator  reference.  18 

Indicates  if  any  reports  are  1 

overdue  or  if  the  node-sector 
telemetry  is  out  of  service. 

To  first  entry  of  a  string  of  6 

fault  reports,  allowing  that 
fault  report  to  be  accessed. 

Permits  the  details  of  that  8 

telemetry  path  to  be  looked 
up  if  it  must  be  restored  or 
its  condition  is  in  question.  _ 


42 


Number  of  Such  Records  -  30  (5  sectors/area  x 

6  nodes/sector) 


Total  Bytes  =  30  x  42  =  1260 
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TABLE  3t13.  STATION  FILE  CONTENTS 


Item  Comments  Bytes 

Station  Name  3 

Station  Status  Indicates  if  the  station  is  1 

totally  or  partly  out  of  service 
or  if  a  HAZCON  exists. 

Link  ID,  Status,  Destination,  Identifies  each  link  terminating  176 


Spare  Trunks  (for  up  to  16  links)  at  the  station,  its  status  and 

destination  and  if  there  are  any 
spare  channels.  Used  for  gen¬ 
erating  status  displays  and  for 
the  operator  to  manually  in¬ 
vestigate  alt  routes. 


Fault  Detail  Pointer  Points  to  first  fault  report  6 

against  the  station,  allows 
that  fault  report  to  be  accessed. 

Responsible  Node  Locates  the  station  within  the  3 

global  data  base. 

Responsible  Sector  Locates  the  station  within  the  3 

global  data  base. 

Responsible  Area  Locates  the  station  within  the  3 

global  data  base. 

AUTODIN  Site  Flag  Indicates  that  an  AUTGDIN  switch  1 

is  at  this  site,  used  in  status 
display  generation. 

AUTOVON  Site  Flag  Indicates  that  an  AUTOVON  switch  1 

is  at  this  site,  used  in  status 
display  generation. 

ATEC  Equipped  Flag  Indicates  that  ATEC  exists  at  this  1 

site,  used  to  determine  if  commu¬ 
nications  with  ATEC  are  possible. 

Manned/Unmanned  Flag  Indicates  if  >the  station  is  a  1 

manned  site,  to  determine  what 
actions  are  possible  or  if  there 
can  be  communications  with  an 
operator. 

CCSD  of  ATEC  Telemetry  to  Node  Permits  reviewing  that  circuit  8 


to  determine  how  it  can  be  restored 
or  other  items  relative  to  its 
operational  status. 
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TABLE  3-13.  f  STATION  FILE  CONTENTS  (Continued) 


Item 


Station  Reporting  Status 


Time  Report  Due 


Reporting  Fault  Pointer 


Comments  Bytes 


Indicates  that  the  telemetry  1 

to  the  site  is  out  of  service 
or  that  reports  are  overdue. 

Indicates  that  the  time  that  4 

an  overdue  report  should  have 
been  submitted. 

Points  to  first  fault  report  6 

relating  to  a  telemetry 

failure.  _ 


218 


Number  of  Such  Records  -  5  stations/node  x 

5  nodes/sector  x 
4  sectors/area  =  100 

Total  Bytes  =  100  x  218  =  21,800 
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TABLE  3-14.  CONNECTIVITY  PATH  FILE 


Item 

Connectivity  Path  ID 
Terminating  Stations 


Comments  Btyes 

2 

Of  Connectivity  path,  identifies  6 
the  path. 


Links  and  Terminating  Stations 
(Variable  -  up  to  12) 

Fault  Pointer,  Direction  1 


Fault  Pointer,  Direction  2 


All  of  this  data  appears  on  the  132 
display. 

Location,  r/t,  link,  trunk,  ckt,  68 
pointer  -  up  to  4  such  faults. 

Gives  basic  information  on  fault 
in  direction  1  to  be  used  in 
formatting  the  connectivity  display 
and  gives  pointer  to  the  fault 
report  record. 

Location,  r/t,  link  trunk,  ckt,  68 
pointer  -  up  to  4  such  faults. 

Same  as  above  except  for 

Di recti  on  2 .  _ 

276 


Number  of  Such  Records  -  25  (based  on  applying  our 

definition  of  connectivity 
paths  to  Europe;  see  Figure 

Total  Bytes  =  25  x  276  =  6900 
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Link  File— The  link  file  is  linked  to  subordinate  trunks  which  would  be 
impacted  by  its  failure,  and  also  to  the  connectivity  path  which  is  impacted 
by  a  link  fault.  There  is  sufficient  information  in  the  file  for  a  sumnary 
link  status.  (See  Table  3-15.) 

Trunk  File— The  trunk  file  is  linked  to  subordinate  circuits  which  would 
be  impacted  by  its  failure,  and  also  to  the  supplying  link  which  is 
partially  degraded  by  a  trunk  failure  and  can  cause  a  trunk  failure.  The 
file  contains  sufficient  information  for  a  summary  trunk  status  and  an 
impact  summary  if  the  trunk  fails.  (See  Table  3-16.) 

Circuit  File— The  circuit  file  is  linked  to  the  supplying  trunk,  which  can 
cause  its  failure,  and  to  the  trunk  record  if  it  is  a  VFCT.  The  file 
contains  sufficient  information  for  a  circuit  status  display.  (See  Table  3-17.) 

Fault  File— The  fault  file  contains  data  related  to  a  specific  fault. 

It  there  are  multiple  reports  filed  on  one  fault,  then  the  Fault  Detail 
pointer  (link,  trunk,  or  circuit)  will  link  those  records  together.  (See 

Table  3-18.  If  this  fault  is  superceded  by  a  higher  level  fault,  then  it  will 
be  marked  closed,  and  a  link  will  be  made  to  that  higher  level  fault.  If 
this  fault  supercedes  another,  then  the  fault  detail  pointer  to  superceded 
faults  will  link  these  together.  In  addition,  all  reports  for  faults 
at  the  same  station  and  all  reports  for  faults  at  the  same  node  will  be 
linked  together. 


TABLE  3-15.  LINK  FILE  CONTENTS 


Item 


Comments 


Link  ID 

Terminating  Stations 

Trunk  List  (up  to  16) 

DOD  (Direction  1) 

Fault  Pointer  (Direction  1) 

DOD  (Direction  2) 

Fault  Pointer  (Direction  2) 
ETR  and  DTG 

Highest  RP 

Connectivity  Path  ID 
HAZCON 

Data  Base  Distribution 


Stations  at  each  end  of  the 
link,  for  information  and  for 
alt  route  sorting. 

Trunk  IDs  for  trunks  riding 
this  link  -  for  impact  summary, 
alt  routing  information. 

Degree  of  degradation  (i.e.,  out 
or  degraded) 

Points  to  first  fault  report, 
direction  1. 

Same  as  for  Direction  1. 

Same  as  for  Direction  1. 

Estimated  Time  to  Restore 

and  Date/Time  group  when  Estimate 

was  made. 

Highest  restoration  priority 
carried  by  the  link  to  establish 
criticality  of  temporary/  permanent 
restoral . 


List  of  all  stations  (2),  nodes 
(2),  sectors  (2),  and  areas  (2) 
to  receive  DB  updates  for  this 
link.  Use  addressing  as  in  ATEC 
10000  Spec. 


Number  of  Such  Records  =  410* 
Total  Bytes  =  410  x  161  =  66,010 


*  Based  on  Reference  28 


/ 


TABLE  3-16.  TRUNK  FILE  CONTENTS 


Item  Contents  Bytes 

Trunk  ID  6 

VFCT  CCSD  Cross  reference  to  VFCT  8 

Identifier  If  this  Is  a  VFCT. 

Link  Assignments  Link  number  (5  bytes),  180 


terminating  stations  (6),  super¬ 
group  number  (1),  group  number  (1), 
type  of  appearance  (terminating 
or  through  group) (1),  assigned 
direction  (transmit  rece1ve)(l), 
and  whether  TCF,  ET,  etc.  (3) 
up  to  10  links.  Permits  identifying 
carrying  links  to  check  link 
status  and  to  reflect  a  partial 
outage  of  the  link  when  the  trunk 
Is  out. 


CCSDs  Carried 


Reroute  ID  #1  and  Flag 

Reroute  ID  #2  and  Flag 


Degree  of  Degradation  (DOD), 
Direction  1  and  Fault  Location 


Degree  of  Degradation  (DOD), 
Direction  2  and  Fault  Location 


List  of  CCSDs  (8  bytes)  and  RP 

(1  byte)  of  each,  up  to  24.  216 

Identifies  the  trunk  which  is  7 

preplanned  for  restoral  of  this 
trunk,  and  whether  it  is  activated. 

Identifies  either  a  trunk  other  than  7 
the  preplanned  reroute  which  was 
used  to  restore  this  trunk,  or  a 
trunk  which  has  preempted  this 
trunk.  A  flag  indicates  that  this 
field  is  idle,  or  that  this  trunk 
has  been  rerouted  or  preempted. 

Identifies  whether  entire  group  or  4 
partial  group  in  direction  1  is 
affected,  whether  this  is  a  partial 
degradation,  out  of  service  or  a 
HAZCON. 

Same  as  above,  except  it  is  for  4 
direction  2. 
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TABLE  3-16.  TRUNK  FILE  CONTENTS  (Continued) 


Item 


Comments  Bytes 


Fault  Pointer,  Direction  1  Points  to  first  fault  report  for 

direction  1. 

Fault  Pointer,  Direction  2  Points  to  first  fault  report  for 

direction  2. 


Route  ID 


Identifies  route  which  this  trunk  5 
ri des . 


Data  Base  Distribution  List  of  all  stations  (6  x  3), 

nodes  (3x4),  sectors  (3x4), 
and  areas  (2  x  3)  to  receive 
DB  updates.  Use  addressing 
as  in  ATEC  10000  Spec. 

Control  Responsibility 

Networks  Impacted  (VON,  DIN,  ...)  Identifies  which  control 

functions  need  the  data. 


Related  Route 
Monitoring  Rgrd  Flag 


Number  of  Such  Records  =  1,250* 
Total  Bytes  =  1,250  x  509  =  636,250 


*  Based  on  Reference  28 
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TA&LE  3-17.  CIRCUIT  FILE  CONTENTS 


Item 


User 


Phone  Number 
RP 


VFCT  Number 


Preempting  CCSD  and  Flag 


Trunk  and  Channel  Number 


Reroute  ID  #1  and  Flag 


Reroute  ID  #2  and  Flag 


Degree  of  Degradation, 
Direction  1,  and  Fault 
Location 


Degree  of  Degradation, 
Direction  2,  and  Fault 
Location 


Comments  Bytes 


Identifies  name  of  person  to  j2 

contact  relative  to  this 

circuit. 

Permits  calling  user.  10 

Restoration  Priority  used  in  2 

impact  analysis  of  outage. 

Identifies  carrying  trunk  if  8 

this  is  a  data  circuit  or  the 
trunk  record  if  this  is  a  VFCT. 
Identifies  that  this  circuit  has  9 

been  preempted  by  the  identified 
circuit. 

For  each  segment  and  terminating  84 

station  up  to  6.  Permits 
identifying  serving  trunks  for 
fault  diagnosis,  e.g.  44  JM  10 
10/12.LKF ,SGT. 

Identifies  the  circuit  which  is  9 

preplanned  for  restoral  of  this 
circuit,  and  whether  it  is 
activated. 

Identifies  either  a  circuit  other  9 


than  the  preplanned  reroute  which 
was  used  to  restore  this  circuit 
which  has  preempted  this  circuit. 

A  flag  indicates  that  this  field 
is  idle,  or  that  this  circuit 
has  been  rerouted  or  preempted. 

Identifies  whether  there  is  a  4 

complete  outage  or  a  degradation, 
and  where  the  fault  is.  Direction  1 
for  circuit  level  faults. 

Identifies  whether  there  is  a  4 

complete  outage  or  a  degradation, 
and  where  the  fault  is.  Direction  2 
for  circuit  level  faults. 


1 
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TABLE  3-17.  CIRCUIT  FILE  CONTENTS  (Continued)' 


Item  Comments  Bytes 

Fault  Pointer,  Direction  1  Points  to  first  fault  report  6 

for  direction  1. 

Fault  Pointer,  Direction  2  Points  to  first  fault  report  6 

for  direction  2. 

Data  Base  Distribution  List  all  stations  (6x3),  48 


nodes  (3x4),  sectors  (3x4), 
and  areas  (2  x  3)  to  receive 
DB  updates.  Use  addressing 
as  in  ATEC  10000  Spec. 

Control  Responsibility  _ 3 

214 

Number  of  Such  Records  =  10,500* 

Total  Bytes  =  10,500  x  214  *  2,247,000 


*  Based  on  7,400  circuits  in  unclassified  portion  of  1978  DCS  connectivity 
data  base,  intra  and  inter  Europe.  This  was  taken  to  be  90%  of  total 
circuits.  A  25%  growth  factor  was  added. 
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TABLE  3-18.  FAULT  FILE  CONTENTS 


Item  Comments  Bytes 

Fault  ID  6 

Station  with  Fault  3 

DTG  (of  original  report)  7 

Severity  Link,  trunk,  or  circuit  1 

level. 

ID  of  Circuit,  Trunk,  8 

or  Link  Effected 

Direction  Direction  of  outage.  1 

RFO  List  of  each  reported,  up  9 

to  3. 

ETR  and  DTG  The  estimated  time  to  repair  11 

and  the  time  at  which  the 
report  was  made. 

DOD  Degree  of  degradation  1 

DTG  of  Fault  Closure  9 

Station  Submitting  Closing  3 

Report 

RP  or  Highest  RP  Serviced  by  failed  capability.  2 

Comments  Narrative  field  of  fault  report  80 

ID  of  and  Pointer  to  Fault  Identifies  a  fault  report  which  12 

Superceding  superceded  this  fault. 

Related  Fault  Pointer  Points  to  the  first  fault  report  6 

related  to  this  fault  report, 
e.g.,  a  transmission  fault 
causing  this  AUTOVON  fault. 


3-71 


TABLE  3-18.  FAULT  FILE  CONTENTS (Continued) 

Item  Comments  Bytes 


Fault  Detail  Pointer 
(link,  trunk  or  circuit) 


Fault  Detail  Pointer 
(to  superceded  fault) 


Fault  Detail  Pointer 
(to  next  fault  report 
at  the  same  station) 

Fault  Detail  Pointer 
(to  next  fault  report 
at  the  same  node) 


Points  to  the  next  fault  6 

report  on  this  link,  trunk  or 
ci rcuit. 

Points  to  the  first  report  of  a  6 

lower  order  which  is  superceded 
by  this  fault,  or  to  the  next 
fault  which  was  superceded  by  the 
same  fault  as  this  report. 


6 


6 


183 


Number  of  Such  Records  =  3,600* 
Total  Bytes  =  3,600  x  183  =  658,800 


3-72 


TABLE  3-19.  SIZE  OF  ITEMS  STORED  IN  NETWORK  CONNECTIVITY  DATA  BASE 


#ASCII 

CHARACTERS  = 


ITEM 

DESCRIPTION 

KBYTES 

ACOC,  Sector, 

Node,  Site  ID 

3  letter  DCA  site  name. 

3 

Reporting  Status 

1  letter  coded  for  O.K. 

1 

Pointers 

6  byte  field  allocated  for 
use  in  internal  file/DBMS 
structure. 

6 

CCSD 

8  characters  per  DCA 
standards,  e.g.  DUUC  9865. 

8 

Station  Facility 
Status 

1  letter  coded  for  O.K., 
degraded,  out  of  service. 

1 

Link  ID 

5  characters  per  DCA 
standards,  e.g.  M0912. 

5 

Site  Flag 

1  character  only,  equipped 
(E),  or  not  equipped  (N). 

1 

Time 

4  digits  of  time,  e.g.,  0930. 

4 

Connectivity 

Path  ID 

2  character  identified, 

00-99. 

2 

Trunk 

6  characters,  44GL09 

6 

DOO 

1  character  encoded  as  is 
site  or  facility  status. 

1 

ETR 

4  characters  of  amount  of 
delay  until  restoral. 

4 

DTG 

Julian  data  (3  digits)  plus 
hours  and  minutes  (4  digits). 

7 

RP 

Restoration  Priority  00.1A...4G 

2 

HAZCON 

1  character  indicates  whether 
or  not  a  HAZCON  exists. 

1 

Fault  10 

Node  reporting  (3  characters) 
and  3  digit  number. 

6 
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3.8  SUMMARY 

Section  III  has  described  the  rationale  for  the  implementation  of  the 
recommended  system  described  In  Section  II.  The  alternatives  considered 
and  the  reasons  for  selecting  particular  approaches  have  been  given. 

Changes  to  equipment  and  the  amount  of  added  equipment  have  been  minimized, 
while  planned  capabilities  have  been  used  where  practical. 

The  software  and  hardware  required  for  the  recommended  system  are  described 
in  Section  IV. 
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SECTION  IV 


FUNCTIONAL  DESIGN  AND  COST  ESTIMATES 

This  section  presents  the  functional  design  and  corresponding  cost  estimate 
for  the  implementation  of  the  recommendations  of  Section  II  and  III  The 
areas  affected  by  our  recommendations  include: 
o  Parameter  acquisition 
o  Subsystem  interfaces 
o  Information  flows 
o  PA/SD/I  algorithms 

Both  hardware  and  software  aspects  of  the  functional  design  are  treated 
in  this  section  as  follows: 

o  Functional  flow  charts  and,  where  appropriate,  hierarchy  charts 
have  been  prepared  for  new  and  modified  software.  These  charts 
detail  the  functions  and  modules  required  to  implement  the 
recommended  modifications. 

o  The  modules  are  then  sized  in  the  context  of  the  functions  requ-ired 
of  them. 

o  The  hardware  modifications  and  augmentations  recommended  are 
similarly  detailed  and  analyzed. 

o  The  software  size  estimates  are  translated  into  the  number  of  man 
days  required  for  implementation. 

o  The  number  of  man  days  required  to  design  the  recommended  hardware 
is  estimated. 
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o  The  cost  of  the  hardware  units  required  to  implement  the  recommenda¬ 
tions  is  estimated. 

4.1  FUNCTIONAL  FLOWS 

An  overview  of  the  recommended  system  wide  functional  flow  is  presented 
in  Figure  4-1.  Individual  functional  flows  have  also  been  prepared  for 
all  recommended  additions  or  changes  to  software  in  existing  or  recom¬ 
mended  DCS  subsystems.  Each  flow  describes  the  set  of  functions  performed 
as  the  subject  subsystem  responds  to  a  specific  input  in  order  to  generate 
a  set  of  outputs.  Hierarchy  charts  have  also  been  prepared  for  the 
AUTOVON,  Network  Connectivity  and  Theatre  Control  Functions  to  be  implemented 
using  the  ACOC-WWOLS  computer  facility.  A  summary  of  the  functional  flows 
prepared  is  contained  in  Table  4-1.  The  functional  flows  themselves  and 
a  brief  description  of  each  follow  in  the  order  presented  in  the  table. 

The  structure  of  the  hierarchy  charts  and  the  details  of  the  functional 
flows  have  been  developed  in  an  iterative  fashion  to  assure  consistency 
within  each  level  of  the  hierarchy  and  completeness  across  all  control 
functions. 

4.1.1  Modifications  to  the  NCC  which  Result  in  a  Subnetwork  Control  Center 
The  SNCC  will  have  all  the  same  software  as  the  NCC  with  one  exception: 

o  All  reports  received  from  the  European  PSN's  will  be  stored  and 
retransmitted  to  the  NCC  in  CONUS. 

Figure  4-2  presents  the  functional  flow  describing  this  change  to  the  NCC 
software. 
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Figure  4-1.  Overview  of  System  Wide  Functiona 


Figure  4-2.  At  the  AUTODIN  SNCC  -  Receipt  of  PSN  Report 
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4.1.2  Modifications  to  the  SB-3865 
Parameter  Collection 

As  currently  designed,  the  SB-3865  collects  the  following  traffic  parameters: 
o  Total  number  of  originated  loop  calls 
o  Number  of  trunk  group  originations 

o  Number  AlB's  in  block 

o  Number  preempts/trunk  group 

It  is  recommended  that  the  SB-3865  be  modified  to  collect  the  following  status 
parameters : 

o  Access  lines 

o  HW  subsystems 

a.  Termination  subsystem 

b.  STED  (Seely  Trunk  Encryption  Device) 

c.  MMI  (Man-Machine  Interface) 

d.  Memory 

e.  Matrix 

f.  Control  complex 

g.  Clock 

h.  Power  unit 


According  to  the  SB-3865  spec,  there  will  be  diagnostic  programs  that  will 
be  able  to  identify  failing  hardware  to  the  LRU  when  used  by  a  craftsman. 
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Parameters  Reported 

It  is  recommended  thatthe  ULS  be  modified  to  report  the  traffic  and  status 
parameters  it  collects. 

A.  Traffic  parameters  will  use  ATEC  report  formats. 

1.  Total  number  of  originated  loop  calls 

2.  Number  of  trunk  group  originations  offer  J 

3.  Number  ATB's  encountered  (ultimate  blockage) 

4.  Number  preempts/trunk  group 

B.  HW  status  parameters  will  use  ATEC  report  formats. 

1.  Trunks 

2.  Access  lines 

3.  Encryption  device 

4.  Hazcon  -  Loss  of  one  copy  of  duplex  equipment  or  ability  to 
switch 

5.  Switch  degradation 

6.  Switch  failure 

HW  and  SW  Modifications 
A.  HW  Mods 

1.  Provide  a  port  on  the  switch  to  which  ATEC  format  reports 
will  be  routed  such  that  this  can  then  be  connected  into 
ATEC-CIS. 
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2.  Provide  communication  line  to  the  CIS. 

B.  SW  mods  -  Change  the  applications  software: 

1.  To  report  traffic  parameters: 

a.  Read  and  record  values  periodically 

b.  Transmit  values 

c.  Zero  out  values  to  start  next  reporting  period 

2.  To  report  hardware  status  parameters: 

a.  Modify  diagnostic  and  routine  software  such  that  the 
results  are  buffered  for  transmission  in  addition  to  inform¬ 
ing  local  attendant. 

b.  Put  the  results  into  the  reporting  channel  for  transmis¬ 
sion. 

The  functional  flows  for  these  changes/additions  to  the  SB-3865 

software  are  presented  in  Figures  4-3  and  4-4. 


4 


4-8 


mrnmmmm 


Figure  4-4.  Within  SB-3865;  Message  Formatting  and  Transmission  Control 


4.1.3  Modifications  to  the  TTC-39  Parameter  Collection  and  Reporting 
It  is  recommendedthat  the  TTC-39  be  made  to  collect  and  report  the  following 
additional  parameters: 

1.  Trunk  routine  failure  -  Use  ICD-004  format  RXX 

2.  Detection  of  "Ring  around  Rosey”  condition  -  Use  ICD-004  format 
R60 

This  information  should  be  recorded  and  placed  into  the  SYSCON  overhead 
channel  as  is  done  for  the  other  parameters  recorded  and  transmitted  by  the 
TTC-39. 

Hardware  Modifications 

As  it  has  been  recommended  that  the  Syscon  Channel  be  used  to  route  all  TTC- 
39  reports  to  Langerkopf  for  breakout  by  a  channel  reconfiguration  unit,  no 
hardware  modifications  to  the  TTC-39  switch  itself  are  required. 

Software  Modifications 

1.  Routine  software  must  be  modified  to  buffer  the  indica¬ 
tions  of  single  trunk  failure.  This  indication  must  also  be  trans¬ 
ferred  to  the  system  control  subchannel . 

2.  TTC-39  software  must  be  modified  to  report  the  detection  of  the 
"Ring  around  Rosey"  condition.  Field  A  of  ICD-004  report  format 
R60  (invalid  message  request)  can  be  used  for  this  purpose. 


Figures  4-5  and  4-6  detail  the  functional  flows  for  these  sortware  modifi¬ 
cations. 


4.1.4  Recommended  Addition  of  the  TTC-39  Report  Consolidation  Processor 


; 

I 
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The  TTC-39  Report  Consolidation  Processor  is  required  to: 

o  Multiplex  the  9  flows  of  ICD-004  reports  from  the  TTC-39  switches 
onto  a  single  telemetry  link  to  the  ACOC  in  ADCCP  format, 
o  Route  directives  from  the  ACOC  to  the  proper  SYSCON  channel  in 
I CD-004  format. 

Figure  4-7  details  the  functions  required  of  this  implementation. 

4.1.5  Recommended  Modifications  to  DSCS 

In  DSCS,  it  is  recommended  that  the  software  be  modified  so  as  to: 

A.  Report  by  exception  up  the  DSCS  hierarchy  to  ACOC. 

B.  Report  status  changes  to  the  ATEC-CIS  in  ATEC  format. 

C.  Maintain  historical  profile  of  effective  isotopic  radiated  power 
(EIRP)  and  received  signal  strength  (RSS)  at  all  levels  of  the 
DSCS  Control  Segment  (CS). 

Figures  4-8  through  4-10  present  the  functional  flows  describing  the 
required  changes  to  the  TCE  and  NCE  software. 

4.1.6  Recommended  Modifications  to  ATEC 

The  changes  required  of  ATEC  are  those  necessary  to: 
o  Implement  SB-3865  reporting  to  ACOC 
o  Notation  of  DSCS  exceptions  within  ATEC 
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Obtain  File  in  Build  Mssg  Raise  Flag  •  EIRP 

End  of  EIRP  EIRP  Local  in  NCE  and  Recorded 

MSRMT  Interval  _  Measurement  _____  display  DB  _____  Message  _  Transmit  __  and 

Queue  Transmitted 


At  the  DSCS  TCE 
EIRP  and  RSS  Monitoring 


DSCS  TCE:  Exception  Reporting 


Each  ATEC  subsystem  must  be  modified  to  work  as  a  message  switch  node 
between  ACOC  and  the  individual  ULSs. 

To  facilitate  ATEC  correlation  of  DSCS  exceptions,  the  node  must  be  able 
to  correlate  DSCS  errors  with  ATEC  detected  failures  and  pass  DSCS 
information  onto  the  sector  if  it  cannot  accomplish  the  correlation 
itself. 

Figures  4-11  to  4-13  detail  the  functions  required  of  these  features  in 
the  CIS,  NCS  and  SCS. 

4.1.7  Recommended  Modifications  to  ACOC-WWOLS 
Two  classes  of  functions  have  been  added  at  the  ACOC. 

1.  Acquiring  data  from  new  sources: 
o  The  AUTOVON  switches 

o  The  AUTODIN  II  Subnetwork  Control  Center 
o  The  ATEC  system 
o  The  DSCS  Control  Segment 

2.  Processing  the  acquired  data  to  detect  and  isolate  stresses, 
maintain  data  bases,  and  provide  displays  in  support  of 
real-time  control  of  AUTOVON,  Network  Connectivity,  and  overall 
control  of  the  theatre. 

The  software  functions  have  been  defined  as  if  they  are  implemented  in 

a  computer  separate  from  the  WWOLS.  Table  4-2  summarizes  the  stimuli 
received  by  ACOC-WWOLS.  The  functional  flows  for  the  software 
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Figure  4-12.  ATEC-NCS  ULS  and  TCE  Message  Processing 
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TABLE  4-2.  SOURCES  OF  INPUT  TO  THE  ACOC-WWOLS  SYSTEM 


SOURCE 

I 

!  MEDIA 

CATEGORY 

© 

ATEC  SECTOR 

AUTOOIN 

(A) 

TERRESTRIAL  TRANSMISSION  SYSTEM 
(TTSI  EQUIPMENT  STATUS 

(B) 

AUTOVON  SWITCH  (SB-386S)  STATUS 

AND  TRAFFIC  PARAMETERS 

(C) 

TTS  PMP  DATA 

© 

SNCC 

AUTOOIN 

(A) 

AUTODIN  PACKET  SWITCH  NODE 

55-1  FAILURE  REPORT 

© 

NCE 

AUTOOIN 

(A) 

DSCS  EXCEPTION  REPORTS 

(B) 

DSCS  HISTORICAL  PROFILE  INFORMATION 

© 

THEATRE  CONTROL 

CRT 

(A) 

CONTROL  ACTION 

FUNCTION 

(B) 

DB  QUERY 

(0 

FREE  FORM  MESSAGE 

© 

NETWORK 

CONNECTIVITY 

CRT 

(A) 

CONTROL  ACTION 

CONTROL 

FUNCTION 

(B) 

DB  QUERY 

(Cl 

FREE  FORM  MESSAGE 

© 

AUTOVON 

CRT 

(A) 

CONTROL  ACTION 

CONTROL 

FUNCTION 

IB) 

DB  QUERY 

(0 

FREE  FORM  MESSAGE 

© 

ACOC 

INTERNAL 

(A) 

DERIVATION  FROM  EXTERNALLY 
PROVIOED  DATA 

(B) 

DB  UPDATE 

© 

TTC-39 

DEDICATED 
LINE  FROM 

(A) 

STATUS  AND  TRAFFIC  PARAMETERS 

TTC-39 

REPORT 

CONSOLIDATION 

PROCESSOR 


/ 


necessary  to  implement  these  modifications  have  been  divided  into  four 
categories: 

1.  ACOC-WWOLS  data  interface  control;  Figures  4-18  and  4-19. 

2.  Theatre  Control  Function;  Figures  4-20  to  4-25. 

3.  Network  Connectivity  Control  Function;  Figures  4-26  to  4-36. 

4.  AUTOVON  Control  Function;  Figures  4-37  to  4-46. 

All  input  to  and  output  from  the  Control  Functions  is  handled  via  I/O 
queues.  The  queue  managers  are  accessed  by  both  the  Control  Functions 
and  the  Electrical  Interface  managers  to  enable  the  transfer  of  information 
between  I/O  buffers  and  the  applications  software.  The  Electrical  Interface 
managers  (AUTODIN  II  and  TTC-39  interfaces)  control  the  transfer  of 
information  into  and  out  of  the  ACOC-WWOLS  complex  itself.  They  move 
reports  between  the  I/O  buffers  and  the  I/O  queues  to  facilitate  this 
transfer. 

The  functional  flows  for  the  Control  Functions  have  been  organized  as 
follows.  Each  of  these  three  functions  has  an  input  queue  which  is  the 
gateway  to  most  processing  incidental  to  the  function.  The  first  chart 
for  each  control  function  examines  the  contents  of  the  respective  input 
queue  and  determines  the  appropriate  next  step.  The  possible  responses 
are  listed  as  the  outputs  of  the  "input  message  processing"  chart  for  each 
function.  The  charts  for  each  response  then  follow  In  the  order  listed. 

An  overview  of  the  functional  Interaction  of  the  three  control  functions 
is  presented  in  Figure  4-14. 
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Figure  4-14.  Functional  Interaction  of  the  Three  Control  Functions 


Hierarchy  Charts  for  Recommended  Additions  to  ACOC-WWOLS 

The  hierarchy  charts  on  the  following  pages  (Figures  4-15 to  4-17) 

have  been  developed  for  each  of  the  four  categories  of  functional  flows. 

One  of  the  charts  encompasses  ACOC-WWOLS  Interface  Control  and  the  Theatre 
Control  Function.  Separate  charts  have  been  provided  for  the  AUTOVON 
Control  and  Network  Connectivity  Control  Functions.  The  Control  Function 
charts  consist  of  seven  levels  of  hierarchy. 

1.  The  top  level  is  the  executive  for  the  specific  control /super¬ 
visory  function. 

2.  The  second  level  consists  of  the  software  responsible  for  adminis¬ 
tration  of  the  acquisition,  processing  and  interfacing  of  data. 

3.  The  third  level  routines  are  the  overhead  functions  making  up  each 
control  function. 

4.  The  fourth  level  routines  are  the  specific  functions  of  each 
general  function. 

5.  The  fifth  level  routines  execute  specific  algorithms  in  support  of 
the  level  4  functions. 

6.  The  sixth  level  routines  are  data  base  interface  routines. 

7.  The  seventh  level  is  an  off  the  shelf  data  base  management  system. 


Figure  4-15.  Electrical  Interface  Management  and  Theatre  Control  Functional  Hierarchy  Charts 
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Figure  4-19.  ACOC-WWOLS  Data  Output  Interface  Control 
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Figure  4-21.  Theatre  Control  AUTODIN  Message  Processing 


UPDATE  ACOC  DB 


Figure  4-22.  Theatre  Control  DB  Change  Processing 
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Figure  4-33.  Connectivity  Control  Operator  Action 
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AUTOVON  Control  Input  and  Timeout  Processing 


Figure  4-38.  AUTOVON  Control  Information  Only  Report  Processing 


Figure  4-39.  AUTOVON  Control  Calls 

Offered  Report  Processing 
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4.2  SOFTWARE  MODIFICATIONS,  ADDITIONS  AND  SIZING 

A  preliminary  software  design  has  been  performed  using  the  functional  flow 
analysis  described  in  Section  4.1.  The  new  or  modified  software  functions, 
routines  and  modules  are  identified  for  each  subsystem  and  control  level. 

A  sizing  analysis  is  provided  for  each  routine  or  module  identified  together 
with  a  description  of  the  software  functions  accomplished. 

4.2.1  General 

The  system  and  subsystem  modifications  and  additions  are  summarized  in  Table 
4-3.  All  the  software  identified  with  the  exception  of  the  ACOC/WWOLS 
software  and  the  software  for  the  Report  Consolidation  Processor  are  modifi¬ 
cations  to  existing  systems.  The  two  exceptions  will  require  new  processors 
and  are  new  systems.  The  detailed  results  of  the  software  sizing  are  given 
in  Appendix  B. 

Program  sizing  is  based  on  estimating  the  number  of  lines  of  HOL  code 
required  to  implement  the  various  program  modules  and  routines.  In  determin¬ 
ing  the  size  of  various  routines,  checks  and  comparisons  with  previous 
program  sizing  efforts  were  made  where  routines  and  functions  were  similar. 
Data  was  available  from  similar  Honeywell  programs,  and  from  CSC  and  Western 
Union  for  similar  systems  and  functions.  See  references  7  and  28. 

The  program  occupancy  for  each  HOL  instruction  used  is  15  bytes.  The 
assumption  is  that  each  HOL  instruction  expands  into  five  assembly  level 
Instructions.  This  expansion  Is  commonly  experienced  in  available  mini¬ 
computers.  Further,  each  assembly  level  instruction  requires,  on  the  average. 
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TABLE 

SYSTEM/SUBSYSTEMS 
AUTODiN  II  -  SNCC 
AN/TTC-39 

SB-3865 

Report  Consolidation 

DSCS-TCE 

DSCS-NCE 

ATEC-CIS 

ATEC-NCS 


/ 


4-3.  SUMMARY  OF  SOFTWARE  MODIFICATIONS 


SOFTWARE  MODIFICATIONS 


Provide  capability  to  transmit  all  PSN 
reports  received  to  NCC-CONUS. 

Provide  single  trunk  failure  message  and 
provide  indication  of  Ring  around  Rosey 
condition. 

Obtain  and  build  messages  for  traffic 
parameters,  obtain  and  build  messages 
for  status  parameters,  obtain  and  build 
message  based  on  hardware  diagnostic, 
provide  and  handle  ATEC-10000  protocals 
and  formats. 

Proc.  Interfaces  nine  SCAU's,  consolidates  reports 

to  single  channel  to  ACOC.  Receives  directives 
from  ACOC  routes  to  proper  TTC-39/SCAU. 

Compute  historical  profiles  for  EIRP  and  RSS 
parameter,  file  for  local  display,  provide 
alarm  thresholds  for  operator  alerting,  trans¬ 
mit  periodically  to  NCE. 

Report  earth  terminal  status  alarms  to  ATEC- 
CIS  using  ATEC  10000  formats  and  protocal. 

Report  alarm  exception  reports  to  NCE. 

Receive  and  file  EIRP  and  RSS  historical  pro¬ 
files  for  local  display,  transmit  to  ACOC. 

Receive  exception  report  from  TCE  record  in 
data  base,  update  display  and  transmit  to  ACOC. 

Message  routing  tables  modified  to  accomodate 
messages  to  and  from  TCE,  to  and  from  ACOC,  and 
from  SB-3865  switchboard. 

Message  routing  tables  modified  as  in  ATEC  CIS. 
Process  TCE  alarm  message  for  correlation  with 
terrestrial  alarms,  store  faults,  transmit 
uncorreclated  faults  to  Sector. 
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TABLE  4-3.  SUMMARY  OF  SOFTWARE  MODIFICATIONS  (Cont'd) 


SYSTEM/SUBSYSTEMS  SOFTWARE  MODIFICATIONS 


ATEC-SCS  Message  routing  tables  modified  as  in  ATEC- 

CIS,  transmit  and  receive  message  from  ACOC 
on  AUTODIN. 

Process  TCE  alarm  messages  from  Node  store 
and  attempt  correlation  with  terrestrial 
alarms. 

ACOC/WWOLS  New  software  system  to  perform  Syocon  functions 

at  the  Theater  level. 


*r. 


1 

J 
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three  bytes  of  storage.  The  result  is  15  bytes  for  each  HOL  instruction 
and  this  value  was  used  to  compute  program  occupancy  requirements. 

Software  routines  that  have  been  estimated  in  numbers  of  assembly  level 
instructions  use  an  expansion  factor  of  3  bytes  per  instruction  to  estimate 
program  occupancy  requirements. 

4.2.2  Subsystem  Software 

The  results  of  the  software  sizing  for  each  subsystem  are  described  below 
and  summarized  in  Table  4-4.  The  subsystems  included  are: 
o  AUTODIN  II 
o  SB-3865 
o  TTC-39 

o  The  Report  Consolidation  Processor 
o  DSCS  TCE 

o  DSCS  NCE 

o  ATEC  CIS 

o  ATEC  Node 

o  ATEC  Sector 

o  ACOC/WWOLS 

AUTODIN  II  -  SNCC— The  AUTODIN  II  system  control  will  be  supported 
in  the  European  Theatre  by  a  copy  of  the  NCC  designated  as  the  Sub-Network 
Control  Center.  The  modification  to  the  software  consists  of  readdressing 
all  messages  sent  to  ACOC  to  the  NCC-CONUS.  Table  B-l  summarizes  the  soft¬ 
ware  sizing  for  the  SNCC  modifications. 
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TABLE  4-4.  SYSTEM/SUBSYSTEM  SOFTWARE  SIZING  SUMMARY 


SYSTEM/SUBSYSTEM 

#  OF 

INSTRUCTIONS 

STORAGE  (BYTES) 

PROG.  DATA 

AUTODIN  II  SNCC 

25H 

375 

- 

SB-3865 

365H 

230A 

6,165 

243 

TTC-39 

105H 

1,575 

24 

Report  Consolidation 
Processor 

1,1 90A 

3,570 

890 

DSCS  TCE 

235H 

3,525 

100 

DSCS  NCE 

210H 

3,150 

200 

ATEC  CIS 

30H 

450 

- 

ATEC  NCS 

275H 

4,125 

- 

ATEC  SCS 

235H 

3,525 

- 

ACOC/WWOLS 

18.575H 

★ 

* 

- 

♦See  Section  4.2.3 

H  =  HOL 

A  =  Assembly  Level 
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SB-3865  Modifications--The  SB-3865  is  modified  to  support 
a  new  I/O  port  through  which  is  reported  traffic  and  status  parameters. 
Traffic  parameters  are  sent  periodically  using  ICD-004  R3,  R4,  R6  and  R44 
message  contents.  Switch  status  parameters  are  transmitted  using  R21,  R22 
and  R23  message  contents  on  status  change  occurrence.  Hardware  diagnostic 
failures  are  reported  in  a  new  message  format.  Output  will  be  in  ATEC  10000 
format  and  protocol.  No  directives  will  be  received.  Table  B-2  summarizes 
the  SB-3865  modifications. 

TTC-39  Modifications— The  TTC-39  software  is  modified  to  provide  a 
new  message  to  indicate  and  identify  a  single  trunk  failure  and  to  use  the 
"A"  field  of  an  R60  message  when  the  reason  for  sending  this  message  is  the 
detection  of  a  "ring  around  rosey"  condition.  Table  B-3  summarizes  the 
modifications. 

Report  Consolidation  Processor  Software--The  Report  Consolidation 
Processor  Software  provides  a  data  concentrator  function  and  is  executed  by 
a  microprocessor.  The  inputs  from  nine  TTC-39  SYSCON  channel  acquisition 
units  are  processed,  consolidated  to  a  single  channel  and  output.  Inputs 
from  the  single  channel  (directives)  are  processed  to  determine  address  and 
routed  to  the  correct  TTC-39.  Input  processing  includes  message  input, 
protocol  handling,  and  error  checks.  Message  processing  includes  format 
conversion,  address  detection,  and  I/O  device  control.  Output  processing 
includes  message  output,  protocol  handling  and  parity  and  LRC  generation. 
Table  B-4  summarizes  the  software  additions  for  this  processor. 
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OSCS-TCE— The  software  in  the  TCP  is  modified  to  provide  additional 
alarming  and  upwards  reporting  for  two  parameters.  Historical  profiles  will 
be  computed  for  RSS  and  EIRP  and  will  be  reported  periodically  to  NCE.  In 
addition,  TCE  alarms  will  be  fault  isolated,  converted  to  circuit  or  trunk 
impacted  and  reported  to  NCE  on  occurrence.  Alarms  affecting  the  terrestrial 
transmission  system  will  also  be  reported  to  ATEC-CIS  over  the  150  baud  data 
communication  channel.  ATEC  10000  formats  and  protocol  will  be  used  on  this 
interface.  Table  B-5  summarizes  these  modifications. 

DSCS-NCE— The  software  modifications  at  the  NCE  are  associated  with 
storing  and  displaying  historical  profiles  on  EIRP  and  RSS,  reporting  this 
data  to  ACOC,  receiving  alarm  exception  reports  and  reporting  them  to  the 
ACOC.  Table  B-6  summarizes  these  modifications. 

ATEC-CIS— The  Communications  Interface  Subsystem  (CIS)  software 
modifications  are  required  in  the  form  of  message  routing  table  changes  to 
accommodate  messages  to  and  from  the  new  subsystems  using  it  as  a  message 
handler/switch.  These  include  messages  to  and  from  ACOC,  the  DSCS  TCE,  and 
the  SB-3865.  See  Table  B-7  for  modifications. 

ATEC-NODE— The  software  modifications  in  the  Node  processor  include 
message  routing  table  modifications  similar  to  those  in  the  CIS  to  accom¬ 
modate  new  message  sources  and  destinations,  the  processing  of  TCE  alarm 
reports  for  correlation  with  TTS  alarms  and  faults,  storage  of  alarm  data 
for  future  alarm  correlation,  and  transmission  of  TCE  alarm  data  to  the 
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Sector  Level  in  the  event  that  correlation  is  not  achievable.  Modifications 
are  summarized  in  Table  8-8. 

ATEC-Sector--The  software  modifications  in  the  Sector  processor 
include  message  routing  table  changes  to  accommodate  new  message  addresses 
and  processing  and  storage  of  TCE  alarm  reports  forwarded  from  the  Node  for 
correlation  with  terrestrial  transmission  system  status.  See  Table  B-9 
for  software  summary. 

4.2.3  ACOC/WMOLS  Software 

The  description  and  design  of  the  software  functions  performed  at  the  ACOC 
level  are  depicted  in  the  functional  flows  presented  in  Section  4.1  These 
functions  are  broken  into  three  areas  of  control :  Theatre  Control , 
Connectivity  Control  and  AUTOVON  Control  as  shown  in  the  hierarchy  charts, 
Figures  4-15,  4-16,  and  4-17. 

Each  software  module  identified  has  been  sized  in  terms  of  estimated  lines  of 
HOL  code  required  to  implement  the  routine  plus  additional  memory  required 
for  data  storage  associated  with  the  routine.  The  sizing  estimates  are 
primarily  for  application  software  and  assume  that  the  host  computer  has 
and  supplies  the  operating  system,  diagnostics,  data  base  management  system. 

The  program  sizing  for  ACOC/WWOLS  is  summarized  in  Table  B-10.  Program 
occupancy,  as  previously  mentioned,  is  based  on  a  ratio  of  15  bytes  of 
storage  for  each  HOL  instruction.  The  total  number  of  HOL  lines  of  code  is 
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18,575;  the  total  program  occupancy,  without  overlays  is  276,750  bytes,  and 
the  total  data  occupancy  is  7,500  bytes. 

Since  the  software  is  functionally  broken  into  three  areas  of  control,  it 
is  possible  to  incorporate  an  overlay  structure  to  minimize  processor 
memory  requirements  and  take  advantage  of  on-line  secondary  storage  capabili¬ 
ties.  The  software  modules  were  divided  into  resident  routines  and  functional 
support  routines.  The  resident  routines  are  high  usage,  high  demand  routines 
such  as  CRT  interface,  I/O  drivers,  and  message  processors.  The  resident 
and  support  overlay  sizing  summary  is  shown  in  Table  B-ll.  The  resident 
routines  require  18,750  bytes  of  memory  while  the  support  functions, 
broken  into  the  three  areas  of  control,  are: 
o  Theatre  Control  27,225 
o  Connectivity  Control  27,750 
o  AUT0V0N  Control  27,375 

The  routines  required  for  each  of  the  three  major  functions  are  shown  in 
Tables  B42  through  B-14.  In  each  major  functional  area,  only  one  sub¬ 
function  need  be  in  memory  at  a  time.  The  AC0C  processor  memory  requirements 
are  determined  by  adding  memory  requirements  for  the  resident  routines,  the 
support  overlays  and  the  largest  functional  overlay  for  each  AC0C  control 
function.  The  largest  memory  requirement  is  selected  and  added  to  the 
estimated  operating  system  and  system  support  software  to  determine  total 
memory  required.  Table  4-5  summarizes  this  process.  The  largest  memory 
requirement  occurs  for  the  Connectivity  Controller  and  requires  95,625 
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TABLE  4-5.  MEMORY  REQUIREMENT  FOR  ACOC 


Element 

Resident 

Support 

Overlay 

Largest 

Functional 

Overlay 

Total 

Occupancy 

(Bytes) 

THEATRE 

18,750 

27,225 

9,750 

55,725 

CONNECTIVITY 

18,750 

27,750 

49,125 

95,625 

AUTOVON 

CONTROL 

18,750 

27,375 

18,000 

64,125 

Operating  System  22,000 

System  Pool  20,000 

TOTAL  Data  Base  Management  20,000 

System 

62,000  Bytes 


Total  Memory  Required 


157,625  Bytes 


bytes  of  memory.  The  operating  system,  based  on  currently  available  real 
time  operating  system  software,  such  as  Honeywell  GCOS  6-400* and  a  TOTAL  data 
base  management  system  require  62,000  bytes  of  memory.  Thus  the  total  ACOC 
memory  requirement  if  157,625  bytes  based  on  this  analysis. 

Secondary  storage  requirements  include  the  display  data  storage  as  well 
as  the  data  base  described  in  Section  3.4.  These  requirements  are  summar¬ 
ized  in  Table  4-6  .  The  total  storage  requirements  for  the  Theatre  data 
base  is  estimated  to  be  3,795,818  bytes. 

4.3  HARDWARE  MODIFICATIONS  AND  ADDITIONS 

The  hardware  modifications  and  additions  required  to  implement  the  parameter 
acquisition,  status  and  performance  data  information  flow  and  the  associated 
software  modifications  are  summarized  In  Table  4i-7. 

In  general,  the  software  modifications  to  the  existing  or  planned  subsystems 
do  not  require  hardware  augmentations  to  accompany  them.  In  all  cases,  the 
minimum  spare  memory  capacity  specified  in  for  the  subsystems  in  question 
ranged  from  20%  to  over  100%  of  the  initial  specified  values.  Of  the  sub¬ 
systems  requiring  in  excess  of  1,000  bytes  of  memory  to  implement  the  soft¬ 
ware  modification,  the  SB-3865  has  the  smallest  memory  (128K  bytes),  The 
sizing  of  the  software  modifications  shows  that  the  SB-3865  also  has  the 
largest  modification  In  terms  of  program  occupancy  and  data  storage  (6,400 
bytes).  Assuming  a  memory  size  of  128K  bytes  (it  may  be  larger),  20%  spare 
capacity  translates  to  25. 6K  bytes  of  usable  memory.  The  SB-3865  modifica¬ 
tions  are  assumed  to  be  made  in  the  spare  memory  provided.  If  20%  spare 
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TABLE  4-6.  THEATRE  DATA  BASE  SIZING  (1  of  2) 


TABLE  4-6.  THEATRE  DATA  BASE  SIZING  (2  of  2) 


SYSTEM/SUBSYSTEM 

HAROWARE  MODIFICATION 

AUTODIN  II  SNCC 

None. 

SB- 3865 

Modified  to  provide 
new  I/o  port  includ¬ 
ing  communi cation 
line  adaptor. 

TTC-39 

None. 

SYSCON  Channel 
Acquisition  Unit 

New  special  purpose 
hardware  developed  to 
extract  and  insert 

SYSCON  from  TTC-39 

Digital  Transmission 

Group. 

Report  Consolidat¬ 
ing  Processor 

New  microprocessor 
based  data  link  inter¬ 
face  and  concentrator 
to  consolidate  9  TTC-39 
SYSCON  channels  into  a 
single  data  link  to  ACOC. 

DSCS  TCE 

None. 

0SCS  NCE 

None. 

ATEC  CIS 

None. 

ATEC  NCS 

None. 

ATEC  SCS 

None. 

ACOC  Level 

New  Processor 
and  peripherals  to 
support  the  ACOC 

Control  functions. 

Note  1. 


Note  1. 


Note  1. 


Note  1. 


Communications  Inter¬ 
face  Subsystem  assumed 
to  have  spare  ports  at 
sites  requiring  access. 
Note  1. 


Note  1. 


Note  1. 


Note  1.  Processor  memory  augmentation  judged  not  to  be  required. 
See  Section  4.3 


memory  is  required  to  be  maintained  after  the  software  modules  are  imple¬ 
mented,  then  an  additional  memory  increment  must  be  added  to  the  system.  We 
are  assuming  that  unless  more  than  half  of  the  spare  memory  is  utilized  by 
a  software  modification,  then  no  memory  augmentation  is  required.  All  of  the 
software  modifications  fall  into  the  category  where  no  hardware  augmentations 
in  terms  of  added  memory  increments  are  required  to  the  existing  systems. 

4.3.1  Specific  Hardware  Modifications  or  Additions 

SB-3865 — The  SB-3865  is  modified  specifically  to  provide  an  I/O  port 
for  reporting  traffic  and  status  parameters  and  hardware  diagnostic  failures. 
It  is  assumed  that  this  I/O  port  is  a  newly  developed,  custom  designed 
processor  interface  including  data  buffering,  universal  asynchronous  receiver 
transmitter,  control  and  timing  and  line  drivers  to  provide  the  150  baud 
asynchronous  interface.  Figure  4-47  shows  a  block  diagram  for  this  I/O  port. 

SYSCON  Channel  Acquisition  Unit— The  SYSCON  Channel  Acquisition  Unit 
is  a  custom  designed  device  for  interfacing  the  digital  transmission  group 
external  to  the  TTC-39  for  the  purpose  of  extracting  and  inserting  data  from 
one  of  the  SYSCON  subchannels  riding  the  16/32  Kbps  overhead  channel. 


Figure  4-48  shows  a  block  diagram  of  the  SYSCON  Channel  Acquisition  Unit. 
Data  from  the  TTC-39  is  clocked  into  the  TX  buffer  by  the  TTC-39  clock.  The 
2901  bit  slice  microprocessor  based  Frame  Sync  circuit  analyzes  the  data  and 
determines  where  the  frame  sync  bit  Is  located,  calculates  the  bit  count 
delta  from  the  sync  bit  to  the  required  subchannel  bit  and  initializes  the 


channel 


Figure  4-48.  SYSCON  Channel  Acquisition  Unit  Block  Diagram 


TX  counter  when  the  next  subchannel  bit  occurs.  This  causes  the  TX  counter 
to  output  a  clock  pulse  to  the  TX  FIFO  (First  In,  First  Out  Shift  Register) 
which  clocks  the  subchannel  bit  into  the  FIFO.  The  TX  counter  is  a  program- 
able  counter  whose  maximum  count  is  determined  by  the  channel  count  program¬ 
mer.  This  device  is  a  set  of  dip  switches  which  tell  the  counter  and  the 
microprocessor  the  number  of  bits  between  subchannel  data  bits.  Thus,  once 
the  TX  counter  is  initialized  by  the  microprocessor,  it  counts  data  bits  and 
each  time  it  reaches  its  programmed  maximum  count  it  causes  the  next  sub¬ 
channel  data  bit  to  be  clocked  into  the  TX  FIFO.  The  TX  Counter  operates 
independently  of  the  Frame  Sync  Microprocessor  except  during  initialization. 
The  Frame  Sync  Microprocessor  alternates  between  the  TX  subchannel  circuit 
and  the  RX  subchannel  circuit  guaranteeing  a  rapid  resync  should  some  system 
problem  make  this  necessary. 

The  receive  circuit  v/orks  in  a  nearly  identical  fashion  except  that  we  wish 
to  insert  data  rather  than  read  it.  Data  comes  in  through  the  RX  FIFO.  When 
the  RX  counter  reaches  its  maximum  count,  the  multiplex  switch  at  the  output 
of  the  RX  Buffer  is  switched  away  from  the  group  data  stream  and  the  FIFO 
data  bit  is  substituted  for  the  one  in  the  input  group  data  stream.  As  in 
the  TX  subchannel  circuit,  the  Frame  Sync  Microprocessor  initialized  the  RX 
counter  and  the  Channel  Count  Programmer  set  the  maximum  count. 

Report  Consolidation  Processor  (RCP)--The  Report  Consolidation 
Processor  is  a  new  system  procured  from  standard,  available  components  for 
the  purpose  of  interfacing  nine  communication  circuits  from  the  SYSCON 
channel  acquisition  units  and  converting  them  to  a  single  2400  bps 
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synchronous  circuit  for  routing  to  ACOC.  The  block  diagram  and  recommended 
configuration  for  this  system  is  shown  in  Figure  4-49.  The  system  consists 
of  the  following  components: 

1  CPU  with  16KW  memory  cabinet  and  power  supply 
1  Dual  diskette  and  adapters 
1  Console  teleprinter  and  adapter 
5  Communication  adapters,  2  sync  lines  each 

This  system  configuration  is  typical  of  those  available  from  Digital  Equip¬ 
ment  Corporation  or  Honeywell  Information  Systems  to  perform  this  task. 
Support  software  and  operating  system  software  are  available  to  support  the 
special  purpose  application  software  identified  in  Section  4.2.2. 

ACOC  Hardware  Recommendations --The  ACOC  hardware  components  recom¬ 
mended  are  shown  in  Figure  4-50.  This  hardware  configuration  is  not  unlike 
the  configuration  required  for  the  ATEC  Sector  processor  since  the  functions 
are  similar.  The  primary  functions  are  associated  with  data  base  and  display 
management.  The  processor  should  be  a  state-of-the-art  16-bit  minicomputer 
whose  average  instruction  time  is  in  the  2-8  microsecond  range.  Memory  cycle 
time  should  not  exceed  one  microsecond  and  the  system  hardware  functions 
should  include  operators  control  panel,  watch  dog  timer,  real  time  clock, 
power  fail /recovery  and  bootstrap  loading  capability.  A  full  set  of  off  the 
shelf  hardware  interfaces  should  be  available  for  the  peripheral  and  communi¬ 
cation  interfaces  as  well  as  proven  support  software.  This  software  should 
include  a  real  time  disk  operating  system,  peripheral  drivers,  data  base 
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Figure  4-49.  Report  Consolidation  Processor  Configuration 


Figure  4-50.  ACOC  Computer  System 


management  system,  and  HOL  compiler. 


Memory  size  initially  is  indicated  at  256K  bytes  providing  63%  spare  memory 
for  growth. 

Peripherals  and  interfaces  required  include  10M  bytes  of  disk  storage  for 
data  base  and  program  storage,  a  magnetic  tape  unit  for  journaling  system 
events,  three  keyboard  display/printer  terminals  to  support  the  Theatre, 
AUTOVON  and  Connectivity  Control  functions.  The  CRT  terminal  equipment 
should  be  similar  to  the  CRT  terminal  specified  in  ATEC  10000  Appendix  90. 
Features  should  include  an  intelligent  terminal  with  24  lines  x  80  characters, 
control  line,  multipage  storage,  full  CRT  cursor  and  video  display  controls, 
function  keys,  protected  fields,  field  tabulation  and  full  ASCII  set  of 
alphanumerics  and  control  characters. 

4.4  HARDWARE  AND  SOFTWARE  COSTS 

Budgetary  pricing  for  the  hardware  and  software  modifications/additions  are 
included  in  this  section.  A  summary  of  costs  are  shown  in  Table  4-8. 

4.4.1  Hardware  Cost  Basis 

For  newly  developed  hardware,  costs  are  presented  for  both  the  non-recurring 
development  and  the  recurring  production.  The  non-recurring  costs  consist 
of  all  costs  necessary  to  obtain  a  productized  unit/ system  and  include: 
o  Engineering  Design  and  Technician  Labor 

o  Documentation  Labor  -Specifications,  Part  I  and  II  Drafting,  O&M 
Manuals 
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o  Material  -  breadboard 

o  Test  -  Plans  and  test  labor 

Recurring  costs  consist  of  production  costs  or  off-the-shelf  equipment  costs. 

Non-Recurring  costs  are  quoted  in  terms  of  man-days  of  labor  and  material 
dollars. 

Recurring  or  off-the-shelf  costs  are  quoted  in  material  dollars. 

SB-3865  I/O  Port  Hardware  Costs--The  budgetary  non-recurring  new 
hardware  development  costs  for  the  SB-3865  Custom  I/O  Port  are  estimated 
as  follows: 

o  Labor  (man-days)  118  man-days 

—Includes  Engineering  design,  documentation, 
drafting,  board  test  software,  technician 
baseboard  test. 

o  Materials  (breadboard  and  test  adapters)  $  700 

The  budgetary  recurring  production  costs  per  unit  Is 
estimated  to  be:  $  1,130 

o  Includes  material,  assembly,  labor  and  unit 
test.  Assuming  50  SB-3865's  deployed  -  total 
cost:  $56,500 

SYSCON  Channel  Acquisition  Unit  Costs— The  non-recurring  costs  are 
estimated  as  follows: 
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o  Labor  (man-days) 


175  man-days 


—Includes  Engineering  design,  documentation, 
technician,  board  test  software,  drafting, 
breadboard  test. 

o  Materials  (breadboard  and  test  adapter)  $  1,000 

The  recurring  production  costs/unit:  $  2,500 

o  Includes  material,  assembly  labor  and  test 

unit.  Total  costs  for  nine  units:  $22,500 

Report  Consolidation  Processor  Costs— Table  4-Sf  shows  hardware 
components  that  make  up  the  RCP.  These  costs  are  representative  of  computer 
hardware  available  off-the-shelf  which  satisfy  the  requirements  required  for 
the  Report  Consolidation  Processor. 

ACOC  Budgetary  Hardware  Costs— Table  4-10  summarizes  the  component 
costs  for  the  ACOC  processor  system.  These  hardware  costs  are  provided  for 
currently  available  off-the-shelf  equipment  configured  to  satisfy  the 
requirements  identified  earlier  In  the  report. 

4.4.2  Software  Cost  Basis 

Budgetary  software  costs  are  quoted  in  man-days  of  labor.  Software  costs 
Include  design,  code,  debug  and  documentation.  Documentation  Includes 
Software  Specifications  Part  I  and  II,  test  plans,  and  users'  manuals.  H0L 
software  is  estimated  at  6  lines  of  code/day.  Assembly  level  language  is 


TABLE  4-^9.  REPORT  CONSOLIDATION  PROCESSOR  COMPONENTS 


an 


1 

CPU,  with  16K  W  Memory,  Cabinet,  PS, 

$  5,550 

1 

Dual  Diskette  unit  and  adapter 

4,000 

1 

Operator  console  and  adapter 

2,900 

5 

Communication  adapters,  2  sync  lines  each 

7,500 

$19,950 
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TABLE  4-10.  ACOC  HARDWARE  COMPONENTS/PRICING 


EQUIPMENT _ 

CPU 

Memory  256  K  Bytes 

10  M  Byte  Moving  Head  Disk  and  Controller 

Magnetic  Tape  Drive  and  Controller 

Multiline  Communication  Processor  with 
Line  Adapters  for  3  CRT  Terminals 
and  2  Sync  Caromlines 

CRT/Keyboard/Hard  Copy  Printer  3  @  $6,485 

Cabinets/Power  Distribution/Memory  Battery 
Backup 


TOTAL 


Optional 

Scientific  Instruction  Processor 
Mass  Storage  Disk  33Mand  Controller 
Line  Printer  and  Adapter 


COST 

$10,000 

30,350 

12,700 

11,000 

4,400 

19,455 

3,560 

$91,465 

5,050 

21,000 

10,440 
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estimated  at  12  lines  of  code/day.  See  Table'/ 4-8  for  the  budgetary  cost  in 
man-days  for  each  system/subsystem. 

4.5  SUMMARY 

Section  IV  has  described  the  software  required  to  implement  the  recommended 
system  in  terms  of: 

o  Functional  flows 

o  Size 

o  Adequacy  of  existing  systems  to  host  the  new  software 
o  Budgetary  costs  to  develop  the  new  software 

The  new  hardware  required  has  also  been  described  and  budgetary  costs  to 
develop  and  procure  it  have  been  estimated. 

The  changes  required  to  the  planned  subsystems  are  minor,  except  in  the  case 
of  the  SB-3865.  This  is  a  result  of  the  comprehensive  reporting  capabilities 
planned  for  the  subsystems. 

Capabilities  of  certain  subsystems  have  been  used  to  simplify  data  acquisition. 
Specifically,  the  routing  of  TTC-39  SYSCON  channels  to  a  central  location 
uses  the  overhead  channel  of  a  Digital  Transmission  Group,  and  SB-3865  reports 
are  routed  through  ATEC. 

The  addition  of  functions  at  ACOC  is  the  most  extensive  modification  to  the 
systems  as  they  are  now  defined.  However,  even  this  is  anticipated,  at  least 
in  part,  by  reference  31. 
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The  next  section  of  the  report  presents  the  parameter  analysis  and  selection* 
which  defines  the  data  flows  used  by  the  system  described  In  Sections  II, 


SECTION  V 


PARAMETER  ANALYSIS  AND  SELECTION 


5.0  INTRODUCTION 

Parameters  available  from  the  subsystems  of  the  DCS  were  reviewed  in  order 

\ 

to  determine:  a)  which  ones  were  useful  for  real  time  control  and  b) 
which  ones  were  useful  to  long  term  engineering  functions.  Parameters 
selected  for  real  time  control  must  satisfy  three  objectives.  First, 
parameters  are  required  which  indicate  that  real  time  controls  are  necessary 
That  is,  the  parameters  will  permit  stresses  to  he  detected  and  isolated. 

The  current  practices  in  this  area  provide  guidance  in  making  selections  in 
this  area. 

Second,  parameters  necessary  to  select  the  control  appropriate  to  a  stress 
situation  must  be  available  to  the  decision  makers.  These  parameters 
must  convey  the  status  of  the  networks. 

Third,  the  parameters  necessary  to  provide  management  visibility  of  the 
networks  must  be  provided.  This  requirement  comes  from  DCA  Circular 
310-55-1  for  non-formatted  reports  (NRs).  To  meet  this  requirement, 
two  techniques  are  possible.  Either  the  reporting  structure  currently  in 
use  to  support  310-55-1  NRs  can  be  retained,  or  these  reports  can  be 
automated.  The  benefits  of  automating  the  310-55-1  NRs  will  be  considered 
on  a  subsystem  by  subsystem  basis. 
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The  criteria  for  selecting  parameters  necessary  for  long  term  engineering 
are  based  on  current  requirements.  There  are  two  areas  of  Interest  In 
long  term  engineering.  First  Is  performance  assessment.  Data  of  use 
in  this  category  Include  fault  histories  and  results  of  performance 
measurements.  Current  requirements  in  this  area  served  as  guidelines. 

The  second  area  In  long  term  engineering  Is  the  need  to  maintain  the 
circuit/trunk  data  base.  DCA  circular  310-65-1  documents  the  data  required 
in  that  data  base.  The  data  which  will  be  required  for  this  prupose  will 
be  any  permanent  reassignment  of  channels  to  different  users. 

For  both  of  these  categories,  data  available  from  the  subsystems  which 
would  fulfill  these  requirements  were  analyzed. 

The  parameters  selected  are  reflected  In  the  displays  and  data  base  described 
in  Sections  II  and  III.  The  following  subsections  discuss  the  parameter 
selection  for  these  subsystems: 

•  AUT0V0N,  TTC-39  and  SB-3865 

•  AUTODIN  II 

•  ATEC 

•  The  DSCS  Control  Segment 
5.1  AUT0V0N  PARAMETER  ANALYSIS 

This  section  contains  the  traffic  and  equipment  status  parameter  analysis 
and  selection  for  the  TTC-39  and  SB-3865  switches.  Reporting  requirements 
for  the  TTC-39  are  detailed  in  ICD-004.  On  the  other  hand,  the  specification 


for  the  SB-3865  contains  no  requirements  for  reporting  SYSCON  information. 
The  SB-3865  does,  however,  record  and  present  a  subset  of  the  ICD-004  infor¬ 
mation  to  the  local  operator.  It  is,  therefore,  recommended  (see  Section 
III  )  that  the  information  recorded  by  the  SB-3865  be  reported  according 
to  the  ICD-004  requirements  for  the  TTC-39. 

5.1.1  Traffic  Parameter  Selection 

The  selection  of  traffic  parameters  is  based  on  that  for  which  system 
control  uses  traffic  parameters.  There  are  two  types  of  information  which 
might  be  obtained  from  traffic  parameters  as  follows: 

o  Status  of  equipment  used  by  or  belonging  to  the  network 
o  Level  of  demand  for  network  service,  i.e.,  traffic  level 

The  use  of  traffic  parameters  for  the  assessment  of  equipment  status  is 
not  recommended  for  the  following  reasons: 

o  All  forms  of  equipment  status  changes  can  either  be  alarmed  on 
occurrence,  or  can  be  monitored  by  scanning  at  frequent  intervals, 
o  Traffic  parameters,  being  driven  by  a  stochastic  process, 
require  extensive  smoothing  before  being  applied  to  an  alarm 
threshold. 

o  Network  equipment  status  changes  have  complex,  nonlinear  inter¬ 
actions  with  traffic  parameters  throughout  the  network, 
o  It  would  be  very  difficult  to  separate  traffic  parameter  changes 
due  to  network  status  changes  from  those  due  to  traffic  level 
changes. 


/ 
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Therefore,  traffic  parameters  should  be  used  only  for  determining  the 
network  traffic  level.  Also,  since  the  history  of  the  actual  traffic 
level  is  completely  independent  of  the  future  traffic  level,  there  is  no 
way  that  traffic  parameters  could  be  used  to  predict  or  trend  traffic 
levels.  Traffic  level  predictions  can  only  be  made  based  on  daily,  weekly 
and  seasonal  business  cycles  and  other  external  information  such  as  DEFCON. 

The  traffic  parameter  selection  matrix  for  the  AUTOVON/AUTOSEVOCOM  TTC-39 
switch  is  shown  in  Table  5-1  that  for  the  SB-3865  is  shown  in  Table  5-2. 

They  are  based  on  the  analysis  contained  in  this  and  the  following 
paragraphs. 

Parameter  Discussion— There  are  three  types  of  traffic  parameters,  as 
follows: 

o  Node  parameters 
o  Trunk  group  parameters 
o  Source-destination  pair  parameters 

Node  parameters  give  information  about  the  traffic  at  the  switch  making 
the  report.  The  node  parameters  defined  in  ICD-004  for  the  AN/TTC-39 
and  SB-3865  are  the  following: 
o  Local  calls  offered 
o  Call  originations  offered 
o  Call  terminated 
o  Tandem  calls 
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erage  number  of  10  X  Area  .65  .65  N/A 

trunks  busy 

Total  8.83  8.83  bits/sec 

♦These  parameters  are  reported  on  each  trunk  group . 


TABLE  5-2.  SB-3865  TRAFFIC  PARAMETER  SELECTION  MATRIX 


o  Calls  blocked,  reported  by  precedence 
o  Calls  with  dial  tone  delay  greater  than  1  second 

The  first  four  parameters  are  part  of  statistical  report  R44,  and  are  avail 
able  In  15,  30,  60,  480,  or  1440  minute  reporting  intervals.  The  last  two 
are  In  real  time  report  R3,  available  In  2.5,  5,  or  10  minute  intervals. 

Node  parameters  do  not  provide  enough  detail  for  real  time  system  level 
control  since  they  either  report  on  strictly  local  problems  or  are  too 
summarized  to  provide  a  clear  picture.  Local  calls  offered  does  not 
provide  any  information  about  network  operations,  and  if  too  many  calls 
have  delayed  dial  tone  the  local  switch  controller  should  apply  traffic 
load  control  to  reduce  the  demand.  Both  parameters  relate  to  strictly 
local  phenomena.  The  remaining  parameters  sunmarize  the  traffic  at  the 
switch,  and  could  indicate  an  overall  switch  overload.  They  provide 
no  detail  about  the  characteristics  of  the  overload,  which  is  needed  to 
Isolate  the  stress.  This  detail  is  provided  by  the  trunk  group  parameters. 

The  TTC-39  can  measure  and  report  trunk  group  parameters  on  up  to  28  trunk 
groups  at  any  given  time.  Since  the  maximum  number  of  trunk  groups  con¬ 
nected  to  any  switch  In  the  AUT0V0N  System  is  9,  for  all  practical  purposes 
the  TTC-39  can  report  on  all  trunk  groups  simultaneously.  The  parameters 
collected  for  each  trunk  group  Include  the  following  counts  of  events: 

o  Calls  offered,  total  and  Itemized  by  precedence 
o  Calls  blocked  due  to  lack  of  idle  trunks 


o  Calls  blocked  due  to  lack  of  common  equipment 
o  Calls  incoming  on  the  trunk  group 
o  Calls  preempted,  by  precedence 
o  Preempts  refused,  by  precedence 

Calls  offered  (attempts)  is  the  basic  traffic  parameter.  It  Is  a  direct 
count  of  every  attempt  to  use  the  trunk  group.  By  assuming  an  average 
time  which  any  call  would  use  the  trunk,  calls  blocked  and  preempted  can 
be  estimated  via  the  Erlang  formulas. 

Calls  blocked  due  to  the  lack  of  idle  trunks  (overflows)  is  the  next  most 
direct  traffic  parameter.  Using  this  count  along  with  the  number  of  calls 
offered  provides  an  estimate  of  trunk  group  performance  which  does  not 
depend  on  assumptions  about  the  hold  times  or  the  statistical  distribution 
of  attempts.  There  are  disadvantages  to  using  this  parameter,  as  follows: 

o  Poisson  statistics,  using  a  historically  derived  hold  time, 
predict  network  performance  fairly  well.  This  is  especially 
true  in  a  network  like  AUTOVON  where  trunk  groups  are  not  used 
as  strictly  high  usage  or  final  trunk  groups  but  have  some  of 
each  kind  of  traffic. 

o  Overflows  are  noisier  than  attempts,  i.e.,  they  come  less  frequently 
and  tend  to  come  in  clumps,  and  thus  a  performance  estimate  based 
on  overflows  would  need  more  smoothing  than  one  based  on  attempts. 
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It  would  be  useful  to  filter  and  threshold  the  ratio  of  overflows  to  attempts 
as  a  backup  to  thresholding  just  attempts  In  case  the  average  hold  time 
changes  drastically  due  to  military  conditions  for  example.  It  must  be 
recognized  that  the  observed  call  blocking  ratio  will  be  slower  to  respond 
when  appropriately  filtered  than  the  attempts  parameter.  Details  of  the 
relationship  will  be  discussed  in  a  later  section. 

Calls  blocked  due  to  lack  of  common  equipment  is  a  management  oriented 
parameter.  Common  equipment  is  normally  sized  in  a  TTC-39  so  that  no  calls 
are  blocked,  even  in  an  overload  situation.  If  calls  are  being  blocked  due 
to  common  equipment,  the  only  control  response  is  to  reduce  originating 
traffic,  a  local  function.  This  is  because  common  equipment  is  not  used  by 
tandem  calls  in  a  TTC-39  network.  The  only  high  level  function  associated 
with  common  equipment  blocking  is  to  allocate  more  units  to  the  switch, 
which  is  not  a  real  time  control. 


Calls  incoming  on  the  trunk  group  is  a  redundant  parameter  which  is  not 
useful  if  the  control  point  has  visibility  of  both  ends  of  the  trunk. 

It  is  just  attempts  minus  overflows  from  the  other  end.  This  parameter 
would  be  useful  if  some  sort  of  distributed  control  scheme  was  contemplated, 
but  it  has  no  place  in  the  DCS  hierarchical  control  structure. 

Calls  preempted  and  preempts  refused  are  indicators  of  the  basic  traffic 
level,  but  they  are  very  noisy  parameters  and  hence  not  useful  for 
real  time  system  control.  They  are  noisy  in  the  sense  that  a  preempt  attempt 
is  generated  only  if  all  alternate  routes  overflow  on  an  idle  search.  Each 
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time  an  overflow  process  occurs,  It  has  a  larger  ratio  of  variance  to 
mean  than  the  arrival  process  which  generated  it.  Since  a  preempt  is  an 
overflow  of  the  final  trunk  group,  prempts  have  a  very  large  variance  to 
mean  ratio.  In  addition  to  being  noisy,  preemption  counts  still  contain 
only  basic  traffic  intensity  data  the  same  as  idle  attempts.  Therefore, 
these  parameters  are  not  useful  for  real  time  system  control .  They  are 
useful  for  long  term  engineering  studies  to  determine  if  the  precedence 
system  is  operating  properly.  In  some  network  designs,  preemption 
algorithms  transfer  precedence  ratings  between  calls  in  an  erroneous 
manner.  This  could  be  detected  by  long  term  analysis  of  preemption  count 
data. 

The  last  trunk  group  traffic  parameter  collected  by  the  TTC-39  is  called 
number  of  trunks  busy.  It  is  obtained  by  scanning  the  trunk  group  every 
30  seconds  and  counting  the  number  of  trunks  either  busy  or  reserved  at 
each  precedence  level.  Those  trunks  which  terminate  locally  are  excluded 
from  the  count.  The  30  second  scan  results  are  then  averaged  over  the 
measurement  interval  of  2.5,  5,  or  10  minutes.  This  parameter  is  similar 
to  trunk  utilization,  which  is  a  traffic  parameter  that  has  been  extensively 
analyzed.  It  is  not  trunk  utilization  however  and  should  not  be  confused 
with  trunk  utilization.  Trunk  utilization  includes  terminating  as  well  as 
tandem  or  originating  calls,  and  is  based  strictly  on  usage,  not  a  reser¬ 
vation.  The  trunks  busy  parameter  in  the  TTC-39  has  been  so  distorted  that 
it  doesn't  really  bear  any  specific  relationship  to  the  traffic  on  the 
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trunk  group  except  that  they  tend  to  move  In  the  same  direction.  It  is 
therefore  not  useful  for  real  time  system  control,  nor  for  long  term 
studies  of  traffic  patterns. 

There  is  only  one  node-node  parameter  In  the  TTC-39.  It  is  calls  completed, 
by  node.  If  its  companion  parameter,  calls  attempted,  or  equivalently  calls 
blocked  were  also  available  it  might  be  of  some  use  In  real  time  control. 

The  ESS4  switch  uses  a  parameter  like  this  for  its  traffic  control  algorithm. 
However,  without  some  knowledge  of  calls  attempted  node  to  node  this  parameter 
is  useful  only  as  a  historical  record  of  node-node  traffic  carried  in  the 
network. 

Smoothing  of  Traffic  Parameters  —  Traffic  parameters  are  random  variables 
and  therefore  typically  have  to  be  smoothed  to  be  useful.  The  smoothing 
required  is  very  much  a  function  of  the  exact  use  of  the  parameter  and 
some  arbitrary  decision  criterion.  In  the  case  of  system  control,  the 
expected  use  of  the  smoothed  parameter  is  to  make  a  decision  whether  the 
observed  parameter  came  from  a  stressed  traffic  situation  or  from  a  normal 
unstressed  traffic  situation.  This  decision  is  made  by  placing  a  threshold 
on  the  smoothed  parameter  value.  An  arbitrary  criterion  for  the  goodness 
of  the  decision  process  can  be  made  by  the  thresholding.  Although  this 
criterion  is  completely  arbitrary,  it  is  reasonable  in  the  sense  that 
if  traffic  alarms  are  continually  being  issued  by  the  system  control  system, 
the  network  controllers  will  soon  learn  to  ignore  the  alarms.  An  average 
of  one  alarm  per  shift  would  probably  be  tolerable. 
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With  these  conditions  we  can  estimate  the  smoothing  time  required  as  a 
function  of  the  definition  of  stress  for  any  traffic  measurement  for 

which  the  mean  and  variance  are  known.  An  appropriate  smoothing  time  can 
be  obtained  by  approximating  the  measurement  distribution  with  a  Gaussian 
distribution  which  has  the  same  variance  in  the  stressed  as  in  the  unstress¬ 
ed  condition.  Then  the  minimum  probability  of  error  is 


2 

where  ^  is  the  mean  of  the  unstressed  distribution 
is  the  mean  of  the  stressed  distribution 
( T  is  the  standard  deviation 

In  general,  the  standard  deviation  is  proportional  to  the  reciprocol  of 
the  square  root  of  the  smoothing  time.  Also,  if  a  sample  of  data  is 
collected,  a  single  decision  is  on  the  data  set,  and  none  of  the  data  is 
reused  in  the  next  decision,  the  average  time  between  errors  is  approximately 

Te  *  A  8  hours 

Combining  these  equations  and  normalizing  to  the  hold  time  yields 
320  erfc  4V5  *  ts 

2  C’l 


where  t$  is  the  smoothing  time  in  hold  times 

A  is  the  difference  between  the  mean  of  the  stressed 
and  unstressed  distributions 

0j  is  the  variance  of  the  measurment  for  a  one  hold 
time  smoothing  interval. 

This  equation  for  smoothing  time  can  be  solved  given  only  the  ratio  of 
A/flTr 


Smoothing  of  Observed  Blocking— A  common  function  used  to  determine 
traffic  conditions  is  the  ratio  of  calls  blocked  (0)  to  calls  attempted 
(A).  The  variance  of  this  function  for  a  wide  range  of  traffic  conditions 
is  shown  in  Figure  5-1 .  This  figure  is  taken  from  reference  (26),  where  the 
variance  of  the  function  was  derived.  Applying  the  equation  for  smoothing 

r 

time  derived  in  the  previous  section  yields  Figures  5-2  and  5-3.  The  general 
characteristics  demonstrated  by  Figure  5-3  and  the  following: 

o  Required  smoothing  decreases  wUh  larger  trunk  groups, 
o  Required  smoothing  decreases  with  heavier  traffic, 
o  Required  smoothing  increases  with  the  peakedness  of  the 
traffic* 

o  Smoothing  time  is  more  sensitive  to  nominal  GOS  than  it  is 
to  the  number  of  trunks  in  the  group  or  the  peakedness  of  the 
traffic. 
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Figure  5-2.  Overflow  Smoothing  Time  as  a  Function  of  Overflows 


REQUIRED  SMOOTHING  (HOLD  TIMES) 
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Figure  5-3.  Overflow  Smoothing  Tine  as  a  Function  of  Threshold  GOS 
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The  definition  of  stress  is  a  matter  of  operational  policy  but,  as  an 
example,  if  it  were  desired  to  detect  a  change  from  .05  GOS  to  .15  GOS, 
the  0/A  ratio  would  have  to  be  smoothed  between  17  and  35  hold  times 
depending  on  the  size  of  the  trunk  group  and  the  traffic  peakedness.  This 
corresponds  to  from  50  to  100  minutes  of  smoothing. 

Thirty  minute  smoothing  would  allow  detection  of  a  change  from  .05  to  .35 
GOS  on  a  6  trunk  group  or  from  .05  to  .25  GOS  on  a  40  trunk  group. 

Since  these  are  fairly  substantial  performance  degradations,  a  30  minute 
smoothing  time  would  be  a  reasonable  minimum  for  smoothing  overflows. 

Smoothing  of  Call  Attempts— An  alternative  traffic  parameter  for  deter¬ 
mining  traffic  level  is  the  number  of  call  attempts,  used  by  itself.  In 
this  case,  the  Erlang  blocking  formula  gives  an  estimate  or  trunk  group 
blocking.  Since  this  is  a  monotonic  relationship,  a  threshold  applied 
directly  to  the  number  of  attempts  will  yield  the  same  results  as  a 
threshold  applied  to  the  trunk  group  performance  estimate.  The  variance 
in  measured  call  arrival  rate,  assuming  a  Poisson  source,  is 

M  ■  4  ♦  4 

z  tz 

2 

where  x  is  the  estimated  arrival  rate.  For  large  t,  the  t  becomes  negligible. 
Since  In  this  case  the  variance  is  proportional  to  the  mean,  some  modification 
of  the  basic  smoothing  formula  is  required.  A  simple,  first  order 
approximation  is  to  use  the  mean  of  the  stressed  and  unstressed  traffic's 
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standard  deviation  as  the  common  standard  deviation.  This  allows  the 
continued  use  of  a  simple  decision  formula  and  provides  a  good  approximation 

for  error  rate.  Figure  5-4 shows  the  resulting  smoothing  time  as  a  function 
of  the  detectable  change  in  GOS.  Compared  to  Figure  5-3  the  smoothing 
times  in  Figure  5-4are  shorter  for  an  equivalent  threshold  and  nominal 
traffic  situation.  Smoothing  times  on  the  order  of  30  minutes  provides 
a  aGOS  sensitivity  of  about  .2  on  small  groups  down  to  .1  on  larger  groups. 
Since,  for  any  smoothing  time,  a  smaller  change  in  grade  of  service  can  be 
detected  using  arrivals  rather  than  the  0/A,  the  arrival  count  by  itself 
is  a  better  parameter  for  traffic  stress  detection. 

The  computations  were  made  based  on  a  very  simple  filtering  mechanism, 
and  a  simple  decision  rule.  More  sophisticated  filtering  algorithms 
and  decision  rules  are  available  to  reduce  these  times  somewhat,  but 
the  basic  conclusion  that  for  reliable  automatic  thresholding  of  traffic 
parameters,  long  smoothing  times  are  required  is  still  valid.  The  general 
trend  of  these  parameters  is  that  for  larger,  more  heavily  loaded  trunk 
groups  the  smoothing  time  is  shorter  whereas  with  smaller,  more  lightly 
loaded  groups  the  smoothing  time  is  longer.  In  any  case,  the 
functions  is  nowhere  near  as  sensitive  to  trunk  group  or  loading  factors 
as  it  is  to  the  threshold  delta  and  time  between  errors  assumptions. 

These  assumptions  must  be  established  according  to  operational  exigencies. 

Relation  of  Traffic  Parameter  to  Network  Status  Parameters--The  use  post¬ 
ulated  for  traffic  parameters  is  to  detect  changes  in  network  traffic  loads. 
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For  any  given  trunk  group,  the  change  can  be  caused  either  by  a  change  in 
the  basic  demand  for  service  or  by  a  change  in  the  network  status.  If  the 
traffic  level  change  is  due  to  a  change  in  network  status,  it  would  have 
been  predictable  based  on  network  status  parameters.  No  further  information 
is  obtained  by  observing  that  the  traffic  levels  respond  to  the  new  network 
status. 

If  the  traffic  alarm  thresholds  are  not  changed,  and  the  demand  for  service 
as  well  as  the  network  status  changes,  there  is  no  way  to  separate  an  alarm 
due  to  network  status  from  an  alarm  due  to  traffic.  Therefore,  whenever 
the  network  status  changes,  the  alarm  thresholds  for  traffic  monitoring 
should  be  modified  so  that  they  still  relate  to  changes  in  the  demand 
for  service  -  i.e.,  they  discount  changes  due  to  a  changed  network. 

This  modification  of  the  threshold  values  can  be  accomplished  by  using 
a  steady  state  model  of  the  network  to  determine  new  nominal  traffic 
values.  Threshold  offsets  of  some  percentage  can  be  applied  to  these 
traffic  values.  These  expected  traffic  values  and  the  resulting  performance 
figures  can  be  presented  to  the  controller  as  further  detail  into  what  the 

status  change  means  relative  to  network  performance. 

/ 

Equipment  Status  Parameters 

The  parameter  attributes  table  for  the  TTC-39  equipment  status  parameters 
is. shown  in  Table  5-3;  that  for  the  SB-3865  Is  shown  in  Table  5-4. 

The  first  three  reports  -  equipment  online,  equipment  standby,  and  equipment 
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TABLE  5-3.  TTC-39  EQUIPMENT  STATUS  PARAMETERS 
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NOTES  t.  ON  OCCURANCE 

1  STATISTICAL  SUMMARY 


failed  -  are  generated  any  time  there  is  a  change  in  the  status  of  the 
components  of  the  TTC-39  or  SB-3865.  With  the  exception  of  pooled  equipment 
failures  when  less  than  25%  of  the  equipments  have  failed,  any  occurrence  of 
these  messages  is  an  immediately  reportable  HAZCON  IAW  DCAC  310-55-1.  There¬ 
fore,  these  messages  must  be  forwarded  to  area  except  when  dealing  with 
pooled  equipment  having  less  than  a  25%  reduction  in  capacity.  Since  most 
occurrences  of  these  messages  must  be  transmitted  anyway,  and  there  is 
currently  no  means  to  suppress  those  messages  which  are  not  required,  it  is 
reasonable  to  transmit  R21,  22,  and  23  whenever  they  occur.  The  thresholding 
of  HAZCON  status  can  be  a  function  of  the  area  level  processor  receiving 
these  reports. 

The  next  three  reports  listed  all  report  on  the  loss  of  a  trunk  group,  for 
various  reasons.  Reports  of  this  nature  are  required  by  DCAC  310-55-1  on 
occurrence.  In  addition,  DCAC  310-55-1  requires  a  report  whenever  25%  of 
any  trunk  group  fails.  There  is  no  parameter  supporting  this  requirement. 

A  change  in  the  software  could  be  made  to  report,  on  occurrence,  any  trunk 
routining  failure.  This  would  satisfy  the  55-1  requirements  for  the  report¬ 
ing  of  trunk  failures  and  is  recommended  to  be  added  to  the  list  of  TTC-39 
and  SB-3865  reports. 

The  invalid  route  request  message  is  generated  only  when  a  call  cannot  be 
completed  due  to  an  error  in  a  routing  table  somewhere.  This  error  could 
affect  critical  subscriber  communications  and  must  be  immediately  corrected. 
The  local  switches  do  not  have  visibility  of  the  entire  network's  routing 
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tables,  so  this  function  must  be  accomplished  at  a  higher  level.  There¬ 
fore  this  report  must  be  forwarded  to  the  area  level  controller  for  action. 
Another  type  of  routing  table  error  with  all  the  same  implications  is  a 
"ring  around  the  rosey"  condition  in  which  a  call's  partial  route  closes  on 
itself.  There  is  no  report  currently  generated  in  this  situation,  and  a 
change  to  the  switch  is  needed  to  provide  one.  The  R60  invalid  route  request 
message  could  be  modified  to  support  "ring  around  the  rosey"  conditions  also 
by  utilizing  field  A  of  the  message  (currently  spare)  to  indicate  which 
condition  is  being  reported  on. 

The  R64  report  is  listed  in  Table  5-3  twice,  once  under  event  parameters  and 
once  under  informational  parameters.  It  is  listed  this  way  because  it 
occurs  both  as  a  consequence  of  automatic  actions  of  the  switch  and  as  a 
result  of  direct  operator  action.  In  either  case  it  is  indicative  of  a  local 
traffic  overload  situation  such  that  local  action  has  been  taken  to  deny 
service  to  some  routine  users.  This  is  an  impaired  service  condition  within 
the  context  of  DCAC  310-55-1,  so  this  report  is  needed  at  the  area  level  in 
real  time. 

Two  more  parameters  are  listed  as  required  for  real  time  use  -  routing  table 
entry  and  area  code  restriction.  These  reports  reflect  changes  that  the 
local  switch  supervisor  has  made  in  the  call  routing  procedures  followed  by 
the  switch.  Changes  in  these  procedures  will  cause  a  shift  in  network 
traffic  load  throughout  the  network.  Furthermore,  one  of  the  major  classes 
of  control  technique  available  to  the  area  level  controller  is  to  modify 
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these  procedures.  Because  of  the  network  wide  impact  of  a  routing  procedure 
change  and  the  need  to  coordinate  changes  made  from  area  with  locally 
initiated  changes,  these  parameters  are  required  at  area  in  real  time. 

The  remaining  set  of  informational  parameters  are  items  which  typically 
would  only  be  changed  in  response  to  a  TSO.  The  reports  generated  are 
information  which,  under  current  procedures  specified  in  DCAC  310-70-1, 
would  be  contained  in  an  "in  effect"  report.  These  items  are  not  needed 
in  real  time  control,  but  they  are  required  to  be  reported  to  the  area  level 
within  72  hours.  In  the  normal  operation  of  a  network,  the  items  reported 
on  would  change  infrequently  such  that  these  parameters  constitute  a  vanish¬ 
ingly  small  communication  requirement.  Since  they  are  currently  reported 
by  the  switch  and  a  modification  or  an  additional  piece  of  equipment  would 
have  to  be  added  to  suppress  their  transmission,  it  is  reasonable  to  allow 
these  parameter  reports  to  go  to  the  area  level. 

An  additional  real  time  status  parameter  not  currently  available  is  recom¬ 
mended  for  addition  to  the  switch-processor  utilization.  Under  the  TTC-39 
software  structure,  self  test  and  system  control  programs  operate  at 
absolutely  the  lowest  priority.  If  for  some  reason  the  switch  processor 
became  overloaded,  the  system  control  programs  might  never  get  executed. 
During  this  situation,  no  reportable  events  can  be  detected.  If  processor 
utilization  were  available  to  the  area  controller,  traffic  shifts  could  be 
made  under  certain  circumstances  to  insure  adequate  execution  of  system 
control  programs.  In  a  more  general  overload  situation,  the  excessive 
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processor  utilization  figures  could  be  used  to  suppress  switch  failure 
alarms  when  traffic  reports  become  overdue. 

5.1.3  Data  Rate  Requirement  for  the  TTC-39 

The  data  rate  requirement  between  the  TTC-39  and  area  has  been  established 
by  considering  a  worst  case  scenario.  This  is  necessary  because  the 
status  parameters  are  transmitted  only  on  occurance  of  a  change  in  state. 

Each  occurrance  requires  the  transfer  of  216  bits  of  information.  A  worst 
case  message  flow  requirement  can  be  established  based  on  this  and  the 
traffic  parameters  previously  selected,  which  will  provide  an  overall 
telemetry  needline.  This  will  not  allow  apportioning  a  part  of  the  needline 
to  each  parameter. 

The  worst  case  situation  is  that  all  traffic  parameter  reports  queue  up  for 
transmission  at  identically  the  same  time,  and  that  immediately  thereafter 
a  status  change  occurs.  A  status  report  is  at  the  same  priority  as  a  traffic 
report  in  the  TTC-39  message  priority  hierarchy,  so  the  status  report  would 
have  to  wait  for  all  of  the  traffic  reports.  The  maximum  number  of  traffic 
reports  from  a  TTC-39  is  31,  broken  down  as  follows: 

1  R3  -  Switch  traffic  status 
9  R4  -  Trunk  group  traffic  status 

9  R5  -  Trunk  group  traffic  status 

5  R6  -  Trunk  group  traffic  status 

1  R27  -  Transmission  group  error  rate 

1  R44  -  Switch  traffic  statistics 
5  R47  -  Switch  traffic  statistics 
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Therefore,  a  delay  of  up  to  32  report  transmissions  can  occur.  If  the 
maximum  acceptable  message  delay  is  set  at  1  minute,  a  115.2  bps  communi¬ 
cation  path  is  required. 

Alternatively,  if  a  120  bps  path  is  provided  and  messages  arrive  according 

to  a  Poisson  distribution,  the  average  message  delay  can  be  computed  from 

basic  queing  theory  results.  The  average  data  rate  for  traffic  messages 

was  previously  shown  to  be  8.83  b/sec  for  the  worst  case  European  switch. 

The  average  time  a  message  spends  on  the  M/D/1  queue  is 

Tq  =  1/u  =  1.8  =  .97  sec 

2(l-e)  2{l-.0y2) 

The  average  time  until  a  message  is  received  is 
T  =  Tq  +  1/  •---  2.77  sec 

Based  on  these  considerations,  a  reasonable  communications  needline  from 
each  TTC-39  switch  to  area  is  120  bps. 

5.1.4  Data  Rate  Requirements  for  the  SB-3865 

A  similar  worst  case  data  rate  can  be  developed  for  the  SB-3865.  If  all  the 
traffic  parameters  that  can  be  recorded  and  relayed  by  the  ULS  queue  up 
simultaneously  just  before  a  status  change,  the  message  queue  for  transmis¬ 
sion  to  ACOC  would  be: 

1  R3  -  Switch  Traffic  Status 

3  R4  -  Trunk  Group  Traffic  Status 

2  R6  -  Trunk  Group  Traffic  Status 
1  R44  -  Switch  Traffic  Statistics 
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1  R21  -  Equipment  Online 
1  R22  -  Equipment  Standby 
1  R23  -  Equipment  Failed 

Therefore,  a  delay  of  up  to  8  report  transmissions  can  occur.  At  216  bits 
per  report,  a  28.8  bps  communication  path  is  required  to  keep  the  maximum 
dal  ay  no  greater  than  1  minute. 

5.2  AUTODIN  II  PARAMETER  ANALYSIS 

The  CONUS  AUTODIN  II  network  has  been  specified  and  designed  as  a  self- 
contained,  self-managed  system  upon  which  WWOLS  collects  long  term  perfor¬ 
mance  and  near  real-time  status  information.  The  functions  and  responsibi¬ 
lities  of  the  DIN  pieces  and  WWOLS  have  been  partitioned  as  indicated  in 
Figure  5-5  which  is  reproduced  from  the  DIN  II  proposal  on  the 
following  page.  Because  the  European  AUTODIN  II  network  requires  surviva¬ 
bility  in  the  event  of  isolation  from  CONUS,  and  because  European  WWOLS 
management  requires  full  theater  visibility,  it  is  proposed  that  an  SNCC 
(Sub-Network  Control  Center)  be  located  in  Vaihingen  which  has  all  the 
functional  capability  and  resources  of  the  NCC.  In  addition,  all  reports 
received  by  the  SNCC  must  be  forwarded  to  the  CONUS  NCC. 

5.2.1  Data  Flow-PSN  to  SNCC 

The  PSN's  in  Europe  will  generate  23  types  of  reports  in  three  categories 
which  are  intended  to  keep  the  network  management  fully  Informed  of  network 
occurrences  relating  to: 


Figure  5-5.  AUTODIN  II  System  Control  Functions  and  Responsibilities 
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o  Traffic  volume-peri odically  and  on  demand 
o  Element  status  -  on  occurrence 
o  Billing-periodically 

Appendix  A  contains  a  report,  characterization  of  an  AUTODIN  II  Node  that 
summarizes  the  contents  and  purposes  of  each  of  these  23  reports. 

5.2.2  Data  Flow-SNCC  to  WWOLS 

The  information  received  in  these  reports  feeds  the  NCC  trending  algorithms, 
the  daily  report  generator  programs  and  the  WWOLS  interface  software.  The 
information  relayed  to  WWOLS  is  summarized  in  Table  5-5.  The  trending 
algorithms  alert  both  the  SNCC  operator  and  WWOLS  via  the  WWOLS  output 
formatting  routines  (WOFR)  of  potential  (TREND)  or  existing  (FAILURE) 
failures  or  of  the  reversal  of  a  previous  TREND  or  FAILURE  as  functions  of: 
o  Blockages  recorded 
o  Preemptions 
o  Buffer  utilization 
o  Processing  delays 
o  Timeouts 
o  Retransmissions 

In  addition  to  passing  on  trending  results,  the  WOFR  also  relay  indications 
of  unscheduled  change  of  status  of  any: 
o  PSN 


o  Access  line 
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TABLE  5,-5.  INFORMATION  RELAYED  FROM  SNCC  TO  ACOC/WWOLS 


Event  Report  Frequency 


1.  Trending  algorithm  detects  a  TREND 

towards  failure,  or  the  reversal  of 

a  previous  TREND. 

On  Occurrence 

2.  Trending  algorithm  detects  a  FAILURE, 

or  the  reversal  of  a  previous  FAILURE. 

On  Occurrence 

3.  STATUS  Change 

o  PSN  Subsystem 

o  Access  Line 

o  1ST 

o  Critical  Switch  Functions 

On  Occurrence 

4.  Program  or  table  reload  at  a  PSN 

On  Occurrence 

5.  Looping  detected 

On  Occurrence 

6.  Interlace  detected 

On  Occurrence 
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o  1ST 


o  Critical  switch  function 

-  Switch  buffering  allocation 

-  Source  switch  connection  control 

-  Source  switch  control  for  access  denial 

-  Destination  switch  timeout  control 

-  Switch  directory  table  update 

-  Switch  outage  and  reload 

-  Interlace  detection 

55-1  reports  bearing  this  information  are  formatted  on  occurrence  to  keep 
ACOC  fully  informed  of  network  and  user  status.  Other  information  that  must 
be  relayed  to  maintain  full  cognizance  at  ACOC  are: 
o  Critical  switch  equipment  status  changes 
o  Notice  of  program  or  table  reloads 
o  Looping  detected  Notices 
o  Interlace  detected  notices 

The  DIN  II  spec  states  that  the  above  information  will  be  correlated  and 
reduced  by  SNCC  software  such  that  WWOLS  will  receive  only  unique  data  from 
the  SNCC.  Because  the  SNCC  is  an  entity  distinct  from  the  WWOLS  computer 
complex,  there  is  no  steady  state  information  flow  rate  between  the  SNCC 
and  WWOLS.  It  is  unreasonable,  therefore,  to  attempt  to  size  such  a 
connection  based  on  average  information  transfer.  Rather,  the  worst  case 
shall  be  considered. 
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Based  on  the  Information  that  will  be  reported  in  real  time  to  WWOLS  in 
a  worst  case  scenario,  the  worst  case  would  be  either: 

o  Loss  of  a  link  containing  a  group  of  DIN  II  access  lines  resulting 
in  a  55-1  message  for  each  access  line. 

o  PSN  fails  in  such  a  way  that  the  switch  still  operates  but  5 
critical  switch  functions  not  essential  to  the  connection  and 
forwarding  of  packets  no  longer  work;  results  in  5  55-1  messages. 

Assuming  that  a  spur  could  contain  as  many  as  15  or  20  subscribers,  the 
former  failure  will  generate  more  information.  Assuming  that  all  20  sub¬ 
scribers  are  attached  to  the  same  PSN  node,  the  failure  reports  will  arrive 
serially  within  two  minutes.  The  arrival  of  each  Failure  Report  at  the  SNCC 
will  spawn  a  55-1  report  addressed  to  WWOLS.  Each  55-1  report  consists 
of  a  4  word  header  followed  by  S,K,U,E,Z  and  A  content  lines  for  a  total 
of  10  lines  at  16  bits  per  line  or  160  bits  per  report.  All  failure  reports 
must  be  delivered  to  WWOLS  within  1  minute  requiring  10  55-1  reports  per 
minute.  Therefore,  the  bit  per  second  rate  required  to  satisfy  this  worst 
case  situation  computes  to: 

(10  messages)  x  (160  bits/message)  _  2g  7  bps 
60  seconds 


5-35 


5.3  ATEC  PARAMETER  ANALYSIS 

The  terrestrial  parameters  available  from  ATEC  selected  for  ACOC  visibility 

C —  '■ 

are  listed  in  Table* 5-6.  The  selection  was  based  on  the  requirement  for 
three  types  of  data  at  ACOC: 

1)  Indications  of  stress  conditions  In  the  terrestrial  DCS 

2)  Data  Indicating  available  transmission  paths  for  restoring  service 

3)  Data  required  to  support  the  transmission  system  performance 
monitoring  program. 

The  definition  of  stress  conditions  relative  to  the  transmission  system 
is  that  a  link  or  trunk  is  out  of  service  or  is  in  a  hazardous  condition, 
or  that  a  special  interest  circuit  or  a  circuit  serving  a  critical/high 
priority  subscriber  is  out  of  service.  The  ATEC  10000  specification 
defines  fault  Isolation  functions  for  the  Nodal  and  Sector  Control  Subsystems. 
The  parameters  required  will  be  a  sunmary  of  the  results  of  these  isolation 
algorithms  formatted  for  transmission  to  ACOC.  The  fault  isolation 
algorithms  will  be  initiated  for  trunk  and  link  outages  by  alarms  in 
the  transmission  system.  Thus,  this  fault  indication  will  come  soon  after 
a  fault  occurs.  Circuit  level  outages  will  be  identified  by  results  of 
in-service  monitoring  or  subscriber  queries.  The  delay  to  such  an  indication 
can  be  considerably  longer  than  the  delay  to  a  trunk  or  link  outage  indication. 
Thus,  other  sources  could  detect  the  outage  sooner  than  in-service  monitoring. 

Results  of  fault  isolation  algorithms  will  be  forwarded  as  soon  as  they  are 
available  via  an  Initial  fault  report,  thus  permlting  immediate  notification 
of  ACOC  of  any  major  problem.  ACOC  can  then  assess  system  status  with  up  to 
date  Information,  instead  of  having  Information  delayed  ten  minutes  as 


TABLE  5-6.  ATEC  PARAMETERS 


TOTAL  556.072  BITS/DAY 

1  ALARM  CORRELATION  IN  ATEC  IS  ASSUMED  TO  HAVE  INHIBITED  TRANSFERRING  6.44  BITS/SECOND 

OF  TRUNK  OR  CIRCUIT  STATUS  IF  THEY  ARE  CAUSED  BY  A  HIGHER  FAULT  LEVEL. 
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currently  provided  by  310-55-1.  Thus,  ACOC  will  at  least  know  what  is 
happening,  if  not  why.  Then  in  10  minutes,  the  details  will  be  forwarded 
and  appended  to  the  initial  report,  as  currently  required  for  310-55-1 
requirements.  This  is  referred  to  here  as  a  follow  up  fault  report. 

The  benefits  of  making  a  partial  report  immediately  are: 

a)  It  provides  a  total  picture  of  theatre  connectivity  status  at 
ACOC  immmediately ,  thereby  assisting  the  process  of  reconstituting 
the  network. 

b)  If  ACOC  is  responding  to  one  ma.ior  outaqe,  the  latest  data  on 
the  remainder  of  the  system  will  be  available.  This  will 
facilitate  dynamic  rerouting  algorithms  being  directed  from  ACOC. 

The  negative  aspects  of  forwarding  status  information  without  human 
editing  includes  the  fact  that  ACOC  personnel  may  tend  to  request  additional 
data  from  the  sector,  thereby  hindering  its  response  to  the  problem.  However, 
the  requirement  to  complete  fault  isolation  before  forwarding  the  message 
to  ACOC  provides  a  filter  assuring  that  the  fault  is  of  at  least  several 
minutes  in  duration. 

The  amount  of  data  to  transmit  was  determined  to  be  60  characters  (83  with 
ATEC  format  overhead)  for  the  initial  fault  isolation  message  and  80  characters 
(103  with  ATEC  format  overhead)  for  the  follow  up  report. 

See  Figure  5-6. 

The  number  of  reports  to  ACOC  per  day  is  based  on  data  from  references 
28  and  29.  The  first  reference  indicated  that  20%  of  the  circuits 
throughout  Europe  have  faults  on  a  given  day.  Assuming  a  node  having 
responsibility  for  some  2,000  circuits,  there  would  be  400  faults 


5-38 


Fault  Report 
Circuit  ID 
Submitting  Node 
Terminating  Locations 
Location  of  Fault 
Time  Out,  Zulu 
Degree  of  Degradation 
Cause  of  Fault 


4  characters 

9  characters  or  Link  ID  or  Trunk  ID 
4  characters 
8  characters 
4  characters 
8  characters 
3  characters 

20  characters  (computer  generated) 

60  characters 


Follow  up  Report 

Fault  Report  # 

Reference  Initial  Report  # 
Submitting  Node 
Location  of  Fault 
Time  of  this  Report 
Degree  of  Degradation 
ETR 

Narrative  Field 


4  characters 
4  characters 
4  characters 
4  characters 
8  characters 

3  characters 

4  characters 

59  characters  (sized  to 
80  characters 


fit  ATEC  80  character  format 


Each  field  includes  spaces  to  separate  fields. 


Figure  5-6.  Contents  of  Initial  and  Follow  up  Reports 
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per  day  per  node.  However,  these  would  not  all  be  reportable.  The  second 
reference  indicates  that  there  are  approximately  30  reported  on  and  120 
unreportable  outages  at  a  major  node  per  day,  and  a  like  amount  for  a  typical 
five  sites  reporting  to  the  node.  Thus,  this  indicates  that  there  are 
some  300  faults  per  day.  These  two  references  agree  reasonably  well.  The 
reporting  approach  described  above  will  yield  30  reportable  faults  per  node 
requiring  an  initial  report,  a  follow  up  report  and  a  closing  follow  up 
report,  or  90  reports  from  each  node. 

In  addition,  there  would  be  some  number  of  the  ultimately  non-reportable 
faults  which  would  be  forwarded  to  AC0C  because  the  current  10  minute 
delay  has  been  rescinded.  This  number  is  estimated  to  be  another  30,  which 
will  have  an  initial  report  and  one  closing  follow  up  report  since  the 
fault  was  not  long  enough  to  be  reportable  per  55-1  requirements.  Thus, 

there  are  150  reports  per  node.  There  are  three  sectors  with  three  nodes 

accounting  for  450  reports  per  sector  and  one  with  two  nodes  accounting  for 
300  reports,  of  which  180  and  120  are  initial  reports  and  270  and  180  are 
follow  up  reports.  An  average  number  of  150  initial  and  235  follow  up 
reports  has  been  used. 

The  second  reference  indicates  that  there  are  also: 

o  2  station  outages 

o  12  trunk  outages 

o  4  link  outages 

o  35  channel  outages 

53  total 
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daily  throughout  the  European  theatre  which  are  also  reportable.  There 
will  again  be  a  number  of  events  which  occur  which  are  not  ultimately 
reportable  but  cause  initial  fault  reports  and  closing  follow  up  reports. 
This  number  is  also  assumed  to  be  53.  For  each  of  the  four  secotrs,  there 
will  be  approximately  14  ultimately  reportable  events,  requiring  14  initial, 
14  follow  up  and  14  closing  follow  up  reports,  and  14  ultimately  not 
reportable  events  requiring  14  initial  and  14  closing  follow  up  reports, 
or  28  initial  and  42  follow  up  reports. 

The  55-1  daily  report  is  also  assumed  to  be  forwarded  over  the  ATEC-WWOLS 

A 

telemetry  path.  This  is  logical  since  the  55-1  daily  report  will  be 
collected  from  the  individual  fault  reports  developed  both  automatically 
by  the  ATEC  system  and  by  the  operator  interacting  with  the  ATEC  system. 

The  size  of  this  transfer  is  estimated  to  be  an  average  of  18,000  characters 
per  sector.  This  is  found  by  using  the  estimate  of  30  reportable  outages 
per  node  per  day,  3.5  nodes  per  sector,  and  100  characters  per  event  This 
yields  105,000  characters  or  840,000  bits  per  day. 

The  data  required  to  indicate  available  transmission  paths  for  restoral  of 
service  includes  that  discussed  above  (i.e.,  outage  information),  as  well 
as  status  of  the  individual  low  priority  circuits.  I.e.,  potentially  any 
change  of  status  of  any  circuit  should  be  reported  on  occurrpnr.p.  However, 
the  selected  alternative  to  this  is  for  the  ACOC  to  request  status  of  low 
priority  circuits  which  are  reroute  candidates  from  the  sector  in  which  the 
circuit  terminates.  This  reduces  the  size  of  the  data  flow  and  the  amount 
of  data  base  updating  at  ACOC.  The  digital  backbone  will  typically  not 
be  the  cause  of  a  single  curcuit  outage.  Instead,  the  user  tail  or  user 
Instrument  will  cause  such  a  problem.  Thus,  if  the  trunk  is  in  service,  the 
backbone  segments  of  the  circuit  will  generally  be  usable  for  altrouting. 
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Therefore,  the  response  to  the  status  query  should  distinguish  between 
backbone  and  user  tail  problems,  which  the  RFO  code  will  do. 

Additional  data  required  to  maintain  visibility  of  resources  available 
for  restoring  service  is  the  altrouting  selected  at  the  Sectors  or 
Nodes.  This  requires  that  altroute  information  be  transmitted  to  ACOC 
on  occurrence.  This  is  referred  to  as  "connectivity  updates".  For  a 
link  outage,  20  percent  or  77  or  the  circuits  of  a  384  channel  link  are 
assumed  to  be  rerouted.  This  is  the  percentage  of  circuits  in  Europe 
which  are  priority  1  and  2.  Only  for  extended  outages  would  rerouting  occur. 
This  would  be  the  number  of  reportable  outages,  assumed  to  be  4  per  day  or 
1  per  sector.  Thus,  there  would  be  77  reroutes  attributed  to  link  failures 
per  sector  per  day.  It  is  assumed  that  20  characters  are  required  for  each 
circuit  restoral.  Packing  these  into  an  ATEC  message  with  80  text  characters 
per  103  transmission  characters  (29%  overhead)  requires  1.29  x  77  x  20  = 

1987  characters  per  day. 

The  number  of  reports  due  to  the  two  station  outages  per  theatre  per  day 
would  depend  on  the  site  of  the  station  .  By  assuming  it  to  have  three 
links,  then  some  of  the  circuits  will  pass  over  two  of  the  links.  The 
total  number  of  circuits  involved  might  be  equivalent  to  1.5  links. 

Ascribing  one  station  outage  to  a  sector,  another  (1.5)  x  1987  characters 
(based  on  the  link  outage),  or  2980  characters  are  required. 

For  the  12  reportable  outages  of  24  channel  trunks  per  theatre  (3  per 
sector)  per  day,  we  have  0.2  channel  restoral s/channel  x  24  channels/ 
trunk  x  3  trunk  outages/day  x  20  characters/outage  x  1.29  overhead  factor  = 
372  characters/day. 
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The  240  reportable  circuit  level  outages  per  sector  per  day  would  all  be 
candidates  for  alt  routing.  One  ATEC  message  would  be  required  for  each 
of  these  alt  routes.  This  message  would  again  require  20  characters  (10 
to  Identify  the  circuit  restored  and  10  to  identify  the  circuit  preempted) 
but  the  overhead,  an  added  23  characters,  is  now  115%.  Thus,  we  require 
240  connectivity  changes  x  20  characters/messages  x  2.15  overhead  factor  = 
10,320  characters.  For  all  four  connectivity  update  types,  there  will  be 
1987  +  2980  +  372  +  10,320  =  15,659  characters/day. 

The  data  currently  required  for  the  performance  monitoring  program  (PMP) 
is  specified  in  DCA  circular  310-70-1.  It  includes: 

o  Idle  Channel  Noise 
o  Received  Signal  Level 
o  Base  Band  Loading 
o  Impulse  Noise 

These  readings  are  submitted  on  the  Q-line  of  the  55-1  daily  report.  The 
transition  to  a  digital,  transmission  system  will  result  in  a  change  in  the 
parameters  necessary  for  the  PMP.  The  ATEC  100C0  specification,  as  cited 
below,  requires  that  hourly  reports  of  the  following  parameters  to  be  used 
for  performance  monitoring,  be  generated  by  the  station: 

o  Mean  and  lowest  received  signal  level  (3. 2. 1.1. 4) 
o  Baseband  degradation  parameters  corresponding  to  mean  and  highest 
degradation  (3. 2. 1.1. 4) 

o  Counts  of  seconds  which  experienced  degraded  RSL,  degraded/ 
baseband,  first  or  second  level  multiplexer  degredation,  and 
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channel  degradation  (3. 2. 1.1.4) 

o  Measured  transmitter  output  power  parameters  (3. 2. 1.1. 5. 1.2) 

These  parameters  are  in  turn  to  be  processed  at  the  Node  and  Sector  to 
calculate  mean  and  standard  deviations  for  the  last  24  hours,  7  days, 
or  30  days.  It  is  recommended  that  they  be  forwarded  to  ACOC  to  be 
collected  into  the  long  term  performance  assessment  files.  This  collection 
can  be  done  every  30  days  because  the  ATEC  system  will  retain  the  data 
for  that  period  of  time. 

Other  parameters  can  be  collected  into  history  files  in  ATEC  if  desired. 

The  list  of  data  to  be  collected  is  programmable  at  the  NCS/SCS.  Thus,  if 
special  data  is  required  for  a  special  purpose,  it  can  be  collected  and 
forwarded  to  ACOC  in  a  similar  manner  to  the  specified  performance  assess¬ 
ment  parameters. 

The  total  transfer  per  day  (ignoring  the  summary  data,  which  is  an 
inconsequential  contribution)  yields  6.44  bits  per  second. 

To  obtain  a  worst  case  estimate  of  the  required  communications  flow, 
a  worst  case  scenario  has  been  defined,  and  the  resultant  comm  flow  require¬ 
ment  sized.  The  worst  case  would  consist  of  a  number  of  unrelated  events 
occurring  within  a  sector,  all  of  which  must  be  reported  to  ACOC.  Since 
alarm  cascading  is  assumed  to  be  suppressed  by  ATEC,  only  one  message 
resulting  from  each  outage  will  be  issued  to  ACOC. 

If  fault  isolation  is  completed  before  a  message  is  sent  to  ACOC,  then 
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any  node  would  have  only  one  message  to  be  transmitted  at  a  time.  The 
rest  would  be  delayed  by  awaiting  their  turn  to  go  through  the  fault 
isolation  processing.  At  the  sector,  messages  from  up  to  four  nodes 
(the  size  of  the  biggest  sector  in  Europe)  would  be  ready  simultaneously. 
If  each  message  were  100  characters,  there  would  be  400  characters  to 
transmit. 

Establishing  a  time  frame  for  telemetry  to  ACOC  of  say,  10  seconds,  a 
40  character  or  400  bit/second  (assuming  10  bits/character)  line  is 
required.  However,  this  ignores  any  delays  due  to  processing  or  awaiting 
processing. 

Another  large  user  of  the  telemetry  path  for  ATEC  will  be  the  connectivity 
updates.  These  updates  will  document  changes  in  connectivity  resulting 
from  temporary  rerouting.  In  the  case  of  an  entire  link  being  out  of 
service,  there  will  be  a  large  number  of  connectivity  changes  occurring. 

If  we  assume  that  20  percent  of  the  circuits  on  the  link  will  be  rerouted 
(equivalent  to  the  overall  percentage  of  intra  European  circuits  which 
are  priorities  1  and  2),  then  77  circuits  will  be  rerouted,  at  worst 
affecting  77  other  circuits  which  have  been  preempted.  In  this  case, 
there  will  be  a  listing  of  circuits  restored  and  circuits  preempted 
using  approximately  10  characters  for  each  circuit.  Thus,  (77  circuits 
restored  +  77  circuits  preempted)  x  10  characters/circuits  *  1540 
characters,  or  15,400  bits  will  be  transmitted. 

The  need  for  this  message  is  to  prevent  attempted  reuse  of  the  same 
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circuits  for  another  restoral.  If  the  preempted  circuits  are  identified 
in  several  minutes,  this  should  minimize  excessive  attempts  to  reuse 
the  same  circuit.  Establishing  an  objective  of  two  minutes  for  transferring 
the  15,400  bits  yields  128  bits/second. 

These  are  the  only  data  transfers  which  are  time  critical  for  the 
transmission  system. 

5.4  DSCS  PARAMETER  SELECTION 

Selected  DSCS  CS  Parameters  must  be  reported  to  both  the  ATEC  node  and 
the  ACOC.  The  recommended  parameters  provide  visibility  of  major 
outages  (trunk  and  link  outages).  This  permits  identifying  critical 
subscribers  impacted  by  the  outage  via  data  base  searches  at  ACOC  and 
the  Node.  It  also  provides  a  suninary  status  of  major  connectivity  paths 
which  may  be  of  use  in  restoring  service  due  to  an  interruption  elsewhere 
in  the  system.  In  addition,  parameters  which  are  anticipated  to  be 
useful  for  long  term  performance  assessment  of  the  DSCS  are  included. 

In  this  case,  parameter  summaries  beyond  those  recommended  in  the  Control 
Segment  Specifications  are  included.  Specifically,  EIRP,  received 
signal  strength,  and  estimated  frequency  errors  are  required. 

The  selection  of  parameters  was  based  on  a  parameter  list  derived  from 
the  DSCS  CS  specifications.  The  appendices  describing  the  data  bases 
were  not  available.  The  recommended  parameters  fer  ACOC  visibility 
are  listed  in  Table  5-7,  with  further  details  in  Table  5-8.  The  total 
list  of  parameters  from  which  these  were  selected  are  contained  in  Tables 
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TABLE  5-7.  DATA  FLOW,  NCE/WWOLS 


TABLE  5-8.  DETAILS  OF  DSCS  EQUIPMENT  STATUS,  OCE/WWOLS 


5-9,  5-10,  and  5-11.  Table  5-9  lists  the  status  and  performance  parameters 
available  from  the  NCD  and  the  TCE.  Table  5-10  lists  the  configuration 
data  which  is  updated  by  the  NCE.  Table  5-11  lists  the  details  of  the 
status  data.  The  recommended  parameters  to  be  sent  to  the  node  are  listed 
in  Table  5-12. 

The  analysis  leading  to  the  reconmended  parameter  list  (Tables  5-7  and 
5-8)  is  discussed  below.  Following  that  is  a  discussion  of  how  the 
required  data  rates  were  estimated. 

Link  Performance.  This  parameter  is  recommended  for  real  time  control 
because  it  indicates  the  ability  of  the  DSCS  link  to  carry  traffic. 

The  parameter  will  be  reported  to  ACOC  and  to  the  responsible  ATEC  Node 
only  when  it  exceeds  specified  thresholds  indicating  that  performance 
is  marginal  or  completely  unuseable.  These  conditions  may  cause  alarms 
in  the  CS,  but  the  types  of  alarms  are  not  identified  in  the  CS  documentation. 
The  parameter  is  trendable  in  the  sense  of  setting  a  threshold  to  indicate 
marginal  performance.  Application  of  short  term  derivatives  is  not 
recommended.  An  historical  profile  of  the  parameter  is  already  specified. 

( i . e . ,  link  performance  summary.)  The  ACOC  or  Nodal  data  base  will  be 
used  to  Identify  circuits  Impacted  by  the  loss  or  degradation  of  service. 

Link  Performance  Summary.  This  parameter  is  used  at  the  ACOC  for  long 
term  engineering.  It  is  selected  as  a  contrlbuter  to  performance 
monitoring  of  DSCS.  It  is  not  trendable. 
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TABLE  5-9.  SUMMARY  OF  STATUS  AND  PERFORMANCE  PARAMETERS  AVAILABLE  (DSCS  CS) 


Need  obviated  by  other  measures.  *  Recommended  once/10  minutes  in  CS  specification. 
Historical  Profile  +  Summary 


E  r. 


03 

03 

03 

03 

03 

03 

03 

03 

t 

CT> 

a> 

o> 

o> 

O) 

Ol 

cn 

cn 

C 

c 

c 

c 

c 

c 

c 

c 

03 

0 3 

03 

03 

03 

03 

03 

03 

cr 

X 

X 

X 

jC 

x 

X 

X 

X 

03 

o 

o 

o 

o 

o 

o 

o 

o 

o: 

c 

e 

c 

c 

c 

c 

c 

c 

V) 

o 

o 

o 

o 

o 

o 

O 

o 

c 

o  o  o 

2  Z  Z 


o  o  o 


D  i- 
3  C 


O  C3 

O  LU  Ul  O. 
O  O  O  O 
«£  Z  Z  <£ 


o  o 
wO  Ul  o  Ul 
ru  o  o  o 
<  z  <  z 


VI 

03 

>> 

O  “O 

U)  CL 

O)  ZD  r- 

+->  0» 
03  C  C 

O  O  C 

•r-  03 


03  03 

i—  “O 

a. 

03  :d 

M—  C  VI 
03  O  03 

>  M- 


VI  c 

a;  o 
+->  o 
*0 

-o  03 
CL  > 
3)  03 


$  5 
-  S 


03  4J 
C  <9 
C  V)  U 
03  01 

X  4->  4- 

U  03  •»- 

“O  «M 

a.  c 

05  ZD  ai 
■*-  “O 

U  r-  K-4 

tie  , 


c 

03 

•M 

X 

o 

03 

“C3 

>, 

•r- 

c 

4-> 

r— 

u 

r— 

O 

03 

o 

1— 

s. 

CL 

X 

o 

U 

Q, 

03 

5 

03 

•r- 

L- 

■o 

03 

3 

13 

3 

£ 

o 

03 

p" 

> 

c 

> 

OC 

> 

3 

>> 

03 

> 

Ol 

to 

03 

> 

•r~ 

o> 

03 

CD 

U 

Ol 

X 

V) 

03 

•r- 

c 

TD 

4-> 

c 

03 

_J 

CO 

03 

•r— 

3 

-J 

4- 

o 

03 

U 

c 

o 

L. 

O 

VI 

to 

4- 

V) 

C 

C 

•r— 

S- 

o 

03 

o 

03 

03 

V) 

>> 

"O 

C 

0) 

13 

>i 

o 

4-> 

•1— 

E 

3c 

OC 

< 

03 

u 

o 

*M 

4-> 

o 

03 

r*“ 

X 

c 

6 

•r 

£ 

•r- 

o 

03 

4- 

•r“ 

S- 

£ 

o 

•r 

5 

CL 

c 

L- 

•i— 

B 

QC 

O 

&- 

cn 

3 

03 

s- 

3 

o 

o 

c 

3 

3 

03 

s- 

O 

c 

cn 

"O 

•M 

cr 

Q 

X 

o 

3 

U 

cr 

C 

03 

O 

• 

•r“ 

•r* 

■f— 

u 

c 

LU 

N. 

cn 

03 

S- 

03 

03 

>> 

X 

N 

o 

L- 

-o 

4- 

o 

o 

Cl 

03 

I- 

to 

Q 

03 

z 

a. 

O 

C 

o 

r— 

X 

CO 

o  0» 

ai  *r-  oo 

4->  -M  >s 

03  03  4->  (J 

CC  C  *F"  *r- 

•r-  *-  S 

(O  +3  O  U 


i  i  i  i  i  i  i  i  a.  i 


o  o 
S’  ° 

03  LU 

■5  ^ 
5  oo 
z  vo 


4-  03 

C  "O 
O  CL 
O  =3 

4->  C 

v>  o 

03  *r- 


C  4- 
O  C 
•r-  O 
4->  O 
03 

t-  o 

X  Ul 


03  O 

o  o 


Useo  For 

TABLE  5-11.  DETAILED  SThTUS  LISTING  Long  Term  Used  For 


Uplink  Power  Margin.  Used  for  real  time  control  at  the  NCE 
level.  Link  Performance  assessment  provides  a  summary  which 
eliminates  the  need  of  this  parameter  above  it. 

Downlink  Power  Margin.  Used  for  real  time  control  at  the  NCE 
level.  Link  Performance  assessment  provides  a  summary  which 
eliminates  the  need  of  this  parameter  above  it. 

Channel  Quality.  Monitoring  channel  quality  is  a  technical  control 
function.  It  is  of  concern  at  the  ACOC  or  Node  when  users  are 
out  of  service.  It  is  assumed  here  that  user  to  user  channel  monitor¬ 
ing  will  occur  in  the  terrestrial  transmission  system  and  therefore 
obviate  the  need  to  report  this  to  ACOC  or  the  Node. 

Digital  Subsystem  Status,  SSME  Status,  Terminal  Equipment  Status. 
Overall  operational  status  and  time  to  restore  for  equipment  that 
causes  a  user  outage  or  a  HAZCON  must  be  sent  to  ACOC  and  to  the 
ATEC  Node.  This  information  must  be  reported  in  terms  of  what 
circuit,  trunk  or  link  is  impacted,  since  neither  ACOC  or  the 
Node  have  a  data  base  relating  equipment  to  circuit,  trunk  or 
link.  It  is  assumed  that  the  individual  error  rates,  snynchoniza- 
tion  indicators,  and  such  are  processed  with  the  DSCS  CS  so  that 
the  actual  cause  of  any  of  these  statuses  being  out  of  tolerance 
is  detected  and  this  is  passed  to  ACOC  as  an  RFO  code.  Therefore, 
the  remainder  of  the  entries  in  these  categories  are  not  selected. 
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Control  Orderwire  Slave  (COS)  Status.  The  Control  Orderwire  Slave 
is  the  normal  TCE  interface  to  the  NCE.  The  operational  status 
is  of  interest  at  ACOC  because  it  indicates  that  the  TCE  is  not 
accessible  to  the  NCE,  and  therefore  that  the  system  responsive¬ 
ness  is  reduced.  If  the  COS  is  out  of  service,  either  the  Critical 
Control  Circuit  (CCC)  or  the  Orderwire  to  the  terrestrial  DCS 
must  be  used  to  report  this  event. 

Calibration  Data.  All  of  this  data  is  indicative  of  details 
of  the  performance  of  the  DSCS  rather  than  the  go/no-go  performance 
indications  for  system  resources.  Thego^o-go  indications  are 
available  via  other  parameters,  e.g.  link  performance  assessment, 
channel  quality,  synchronization  of  receivers  and  multiplexers, 
etc.  Therefore,  these  parameters  are  not  useful  for  real  time 
control  at  the  ACOC  or  Nodal  level. 

Some  of  them  are  needed  as  indicators  of  long  term  performance  of 
the  DSCS  and  should  be  reported  to  ACOC.  The  link  performance 
assessment  data  alone  can  indicate  whether  or  not  the  link  is 
performing  per  specification.  However,  analysis  of  what  each 
component  of  the  system  contributes  to  the  overall  link  performance 
is  possible  only  through  these  parameters.  For  example,  only  by 
knowing  the  received  C/KT  and  transmit  EIRP  for  a  link  can  the 
contributions  of  each  segment  of  a  link  to  overall  link  performance 
be  analyzed.  In  other  words,  the  actual  system  attributes  required 


to  meet  the  link  performance  assessment  goal  can  be  identified. 

The  pilot  signal  strength  can  also  be  of  use  in  such  an  analysis. 

The  frequency  error  data  will  allow  performance  analysis  of  the 
timing  systems  throughout  the  DSCS.  In  both  of  these  cases, 
multiple  components  of  the  DSCS  are  involved.  Thus,  these  items 
are  recommended  for  use  in  long  term  engineering.  They  will  be  of 
use  at  ACOC  or  DCAOC.  However,  their  historical  surrmary  might 
be  retained  in  OCE  or  NCE  data  bases  and  accessed  as  needed. 

Daily  summaries  of  these  parameters  are  appropriate,  i.e.,  the 
smallest  and  largest  values. 

The  estimated  doppler,  the  difference  between  expected  and  received 
pilot  signal  strengths,  and  the  difference  between  expected  and  received 
beacon  signal  strength  are  not  necessary  for  system  wide  long 
term  engineering  because  they  primarily  reveal  information  about 
the  local  facility  rather  than  about  overall  system  performance. 
Specifically,  the  estimated  doppler  depends  on  the  actual  satellite 
movement  and  the  local  calibration  equipment.  The  satellite 
movement  is  being  controlled  by  the  SCCE  so  that  data  about  it 
from  this  terminal  is  unnecessary.  The  differences  in  signal 
strength  are  primarily  due  to  local  weather  conditions.  The  NCE 
uses  this  data  for  adjusting  transmitter  power  allocations  in  real 
time.  This  data  reflects  temporary  environmental  conditions 
rather  than  long  term  system  performance,  and  is  therefore  not 
useful  for  long  term  assessment. 
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Calibration  Data  Settings.  This  is  information  supplied  to  the 
terminal  to  operate  the  calibration  and  test  subsystem.  It  does 
not  give  information  on  system  performance  and  is  therefore  not 
of  interest. 

Enabled  Alarms.  The  enabled  alarms  are  unspecified.  They  are 
discussed  in  reference  SS-TCE-140,  page  21.  It  is  presumed  that 
they  are  results  of  violating  performance  thresholds,  losses  of 
sync,  and  similar  phemonenon.  These  phenomena  have  been  accounted 
for  in  equipment  status  and  link  performance  assessment.  If  there  are 
other  alarms  that  cause  interruptions  of  subscribers,  they  must 

also  be  transmitted  to  ACOC.  They  must  be  related  to  the  CCSD, 
trunk  or  link  which  they  affect. 

Alarm  Message.  This  is  also  found  in  reference  SS-TCE-140,  page  21. 

The  relationship  of  this  to  alarms  is  unspecified.  It  could  be 
the  description  of  the  cause  of  the  alarm,  discussed  in  the  alarm 
paragraph.  It  has  been  ignored. 

Text  Message.  It  is  assumed  that  this  is  used  for  coordination.  There¬ 
fore,  it  is  specified  to  be  used  as  required. 

Configuration  Data.  The  configuration  data  (see  Table  D-4)  maintained 
by  the  NCE  and  TCE  includes  parameters  necessary  to  identify  the 
multiplex  hierarchy  in  the  Earth  Terminal,  the  circuit  assignment 


of  each  channel,  and  the  specific  type,  priority,  quality,  etc., 
of  each  channel  or  trunk.  This  is  described  in  reference  SS-TCE-140, 
page  13.  Updates  issued  by  the  TCE  or  NCE  will  be  sent  to  ACOC 
as  confirmation  of  a  TSO  or  as  indication  of  a  temporary  deviation 
from  the  normal  configuration.  This  is  consistent  with  the  practice 
of  keeping  the  DOCC  connectivity  data  base  up  to  date,  as  well 
as  providing  the  data  necessary  to  rapidly  identify  availability 
of  resources  for  altrouting. 

DSCS  Control  Segment  Data  Rate  Requirements 

The  interfaces  of  concern  relative  to  the  DSCS  Control  Segment  are  those 
defined  to  support  system  level  System  Control,  i.e.,  the  NCE/WWOLS  interface 
and  the  TCE/CIS  interface.  The  parameters  are  listed  in  Table  .  The 

development  of  bit  rates  required  for  them  is  discussed  in  the  following 
paragraphs. 

The  current  Link  Performance  Assessment  is  transmitted  to  ACOC  whenever 
the  performance  is  out  of  specification,  i.e.,  whenever  the  link  is  degraded 
or  out  of  service.  By  the  mid  1980's,  the  Atlantic  and  Indian  Ocean  satellites, 
which  are  the  primary  suppliers  of  satellite  service  to  the  European  theatre, 
will  support  20  to  40  DCS  links  each.  There  will  also  be  non-DCS  links. 

NCE  will  presumably  be  monitoring  the  performance  of  these  links  to  assure 
that  they  are  operating  per  requirements.  (This  may  in  fact  be  done  by 
subnet  controllers  who  ask  for  service  from  the  NCE  only  when  they  determine 
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that  action  is  required.)  The  OCE  and  WWOLS  concern  with  the  non-DCS  users 
is  only  what  satellite  resources  they  use  which  might  be  used  by  the  DCS 
in  a  contingency.  Therefore,  only  performance  of  the  DCS  links  will  be  sent 
to  OCE/WWOLS.  There  would  be  expected  to  be  only  about  two  DCS  link  problems 
per  day  per  satellite/NCE.  The  message  would  be  similar  to  that  for  a 
terrestrial  fault,  about  60  characters  plus  overhead  for  the  initial  and  80 
characters  plus  overhead  for  two  follow  up  reports. 

The  link  performance  summary  will  require  one  message  per  link  per  day, 
or  approximately  30  messages  per  NCE.  This  is  also  assumed  to  be  about 
60  characters  plus  overhead. 

Equipment  status  will  be  reported  on  an  exception  basis.  There  are  five 
DCS  terminals  in  Europe.  (See  the  deployment  model  in  the  first  report.) 

However,  the  NCE  is  actually  concerned  with  all  of  the  Earth  Terminals 
serviced  by  its  satellite.  Therefore,  there  will  be  probably  15  or  more 
terminals  for  each  NCE  on  which  to  report  equipment  status.  Of  these 
terminals,  only  the  fault  reports  on  those  in  the  European  theatre,  used 
by  the  DCS,  will  be  of  interest  to  ACOC  Europe.  Those  terminals  used  by 
the  DCS  but  in  other  theatres  will  ultimately  be  of  interst  to  DCAOC  or 
ACOC-Pacific.  Their  status  can  be  reported  to  DCAOC  or  ACOC-Pacific  over 
direct  communication  paths  from  the  NCEs  ot  DCAOC  or  ACOC-Pacific.  Alternatively 
the  data  can  be  sent  to  ACOC-Europe  and  forwarded.  Because  paths  are  planned 
between  each  NCE  and  all  ACOC  or  DCAOC  locations  served,  the  direct  path 


-_x_ 


is  preferred.  Thus,  only  status  of  the  five  European  DCS  terminals  will  be 
reported  to  ACOC-Europe. 

The  quantity  of  equipment  status  reports  depends  on  the  amount  of  equipment 
at  the  site.  Typically,  a  terminal  will  have  individual  circuit  appearances 
using  a  relatively  large  amount  of  equipment.  If  this  is  likened  to  a 
terrestrial  DCS  Node,  then  30  reportable  faults  per  day  would  again  be 
expected.  However,  there  will  probably  be  fewer  circuits  with  user  tails 
homed  on  the  site,  since  the  terminals  are  not  in  areas  of  subscriber 
concentration,  nor  do  they  usually  have  collocated  VON  switches.  Thus,  it 
is  estimated  that  there  will  be  about  15  reportable  faults  per  day,  yielding 
15  initial,  15  follow  up,  and  15  closing  follow  up  reports.  For  reports 
that  are  not  reportable,  the  estimate  of  15  initial  and  15  closing  follow 
up  reports  will  be  applied,  as  for  the  terrestrial  system.  For  the  five 
European  terminals,  used  by  the  DCS,  this  amounts  to  5  x  (30  initial  fault 
reports  +  45  follow  up  fault  reports).  The  ATEC  message  sizes  of  83  and 
103  characters,  respectively,  are  applied.  Calibration  data  might  also  be 
referred  to  as  performance  assessment  data.  Twenty-four  hour  summaries  of 
five  selected  calibration  data  items  are  forwarded  to  ACOC.  Two  of  these 
are  link  parameter,  and  three  are  terminal  parameters.  If  all  links  and 
terminals  are  reported  to  one  ACOC,  then  for  (an  estimated)  30  links,  60 
reports  must  be  sent,  and  for  15  terminals,  45  reports  must  be  sent.  The 
report  must  contain  the  following: 
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o  resource  identifier  (link  or  terminal)  -  6  characters 
o  parameter  identifier  -  10  characters 
o  maximum  value  -  10  characters 
o  minimum  value  -  10  characters 

o  reporting  facility  -  4  characters  (3  letter  site  identifier 
plus  1  letter  to  identify  it  as  an  NCE) 
o  Total  -  40  characters 
o  Total  with  overhead  -  48  characters 
Thus,  the  NCE  will  contribute  75  reports  x  48  characters  or  3600  characters/ 
day. 

The  alarm  messages  are  assumed  to  be  elaboration  on  any  performance  assess¬ 
ment  violations  or  equipment  status.  Thus,  they  were  accounted  for  in  those 
categories. 

Text  messages  are  assumed  to  be  coordination  and  resource  allocation  related. 
At  the  NCE/0CE/WW0LS  interface,  there  will  be  little  interaction  other  than 
for  resource  allocation.  It  is  expected  that  no  more  than  20%  of  the  faults 
would  require  communication  via  text  messages.  Thus,  the  150  daily  faults 

reported  to  AC0C  would  yield  30  text  message  interchanges.  Sizing  these 
at  250  characters  each  (a  liberal  narrative  message  size)  another  7500 
characters  per  day  (toward  AC0C)  are  required. 

The  most  frequent  configuration  updates  for  DSCS  will  be  at  the  channel, 
multiplexer  or  link  levels.  For  temporary  changes  in  the  configuration. 
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an  update  of  all  Items  listed  in  Table  (configuration  updates)  is  not 
required.  Typically  what  will  happen  is  that  a  new  link  or  multiplex 
group  will  be  established  to  serve  a  short  term  requirement.  Or,  the  circuit 
assigned  to  one  channel  will  be  pre-empted  to  permit  that  channel  to  carry 
a  different  circuit.  This  latter  case  is  more  appropriately  handled  in  the 
terrestrial  system.  In  the  event  that  jamming  occurs,  a  message  will  be 
sent  listing  the  circuits  which  have  been  pre-empted  or  the  message  will 
state  that  a  specified  plan  has  been  implemented.  Since  the  reaction  to 
jamming  is  expected  to  be  preplanned,  and  the  latter  technique  simplifies 
the  message,  that  technique  is  recommended. 

Thus,  the  configuration  updates  are  in  the  areas  of: 

o  new  links 

o  new  multiplex  groups 

o  notification  of  implementation  of  janming  countermeasures 

There  will  be  relatively  few  such  transmissions.  An  estimate  of  two 
temporary  links,  two  temporary  multiplex  groups,  and  no  counter  measures 
will  be  assumed  to  occur  per  day  in  one-satellite  terminal.  These  would 
be  typically  a  100  character  or  less  message.  Thus,  four  100  character 
messages  per  terminal  would  be  required.  For  the  five  DCS  terminals  in 
Europe,  there  could  be  20  such  messages. 
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The  spare  resources  messages  will  occur  whenever  there  is  a  change  in  the 
overall  system.  Extending  the  estimated  two  link  and  two  multiplex  group 
changes  per  terminal  per  day,  fifteen  terminal  network  would  yield  sixty 
such  resource  changes  per  day.  The  message  will  contain  approximately 
the  following  information: 

o  Date  and  Time  -  7  characters 
o  Satellite  ID  -  4  characters 
o  Transponder  IF  -  4  characters 
o  Bandwidth  Utilized  -  4  characters 
o  Power  Utilized  -  4  characters 

o  Total  -  23  characters 

Overhead  -  23  characters 
46  characters 

Totaling  all  of  the  data  types,  the  average  flow  is  1.5  bits/second. 

A  worse  case  scenario  would  more  usefully  size  the  transfer  rate  requirement 
For  example,  if  it  was  desired  to  establish  new  links,  an  exchange  involving 
several  transfers  of  messages  each  direction  might  occur. 

It  is  assumed  that  this  is  a  250  character  text  messages.  Simultaneously, 
status  messages  and  link  performance  messages  might  be  queued  up.  Let 
there  be  five  such  messages,  for  515  characters  (all  follow  up  reports). 
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A  total  transaction  of  sending  a  text  message  and  receiving  a  response 
(l.e.,  an  acknowledgment  that  the  message  Is  being  responded)  should  take 
a  maximum  of  30  seconds.  Allowing  ten  seconds  for  the  transfer  in  one 
direction  would  require  that  the  (250  +  515)  characters  be  passed  in  ten 
seconds,  assuming  a  single  first  in  first  out  queue  with  the  message  at 

the  end  of  the  queue.  This  results  in  a  612  bps  rate  requirements. 

The  interface  to  the  ATEC  CIS  will  carry  only  items  1,  2,  4,  5,  and  8 
of  the  chart.  Configuration  updates  will  come  via  NCE.  These  will  be  from 
an  individual  TCE,  so  that  there  will  be  one-fifth  the  number  of  messages 
shown  in  the  initial  table.  Table  lists  the  data  flow  for  the  TCP/CIS 
interface.  The  average  rate  is  only  0.1032  bps.  The  most  important 
exchange  will  be  the  reports  relative  to  link  performance  degradation  or 
equipment  status.  The  150  bps  line  can  send  one  of  these  messages  per 
second,  making  that  line  quite  adequate. 
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ACOC 

A/D 

ADC 

ADCCP 

AFSCF 

AFSTC 

AGC 

AN-FSC-78 

AN-GSC/24 

AN-MSC/C1 

AN-USC/28 

ANSI 

ASA 

ASCT 

ATB 

ATEC 

AUTODIN 

AUTOSEVOCOM 

AVOW 

BC 

BER 


Area  Communications  Operations  Center 

Analog/Digital 

Automatic  Digital  Counter 

Advanced  Data  Communications  Control  Procedure 

Air  Force  Satellite  Control  Facility 

Air  Force  Satellite  Test  Center,  part  of  AFSCF 

Automatic  Gain  Control 

Heavy  Terminal 

Asynchronous  Multiplexer 

Mobile  Terminal 

Spread  Spectrum  Modem 

American  National  Standards  Institute 

Automatic  Specturm  Analyzer 

Auxiliary  Satellite  Control  Terminal 

All  Trunks  Busy 

Automated  Technical  Control 

Automatic  Data  Interchange  Network 

Automatic  Secure  Voice  Communication  Network 

Analog  Voice  Orderwire 

Block  Control 

Bit  Error  Rate 

Baseband  Interface  Subsystem 


BIS 
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BKB 

BPSK 

bps 

CCC 

CEI 

CESE 

CIS 

CIT 

C/kT 

CMC 

CODEC 

COM 

COMSEC 

COS 

COSS 

CPC 

CPCI 

CPU 

CS 

CT 

CRT 

CVSD 

CX-11230 


Bookkeeping  Block 
Biphase  Shift  Keying 
Bit  per  Second 
Critical  Control  Circuit 
Contract  End  Item 

Communications  Equipment  Support  Element 

Communications  Interface  Subsystem  (ATEC) 

Controller  Interface  Terminal 

Ratio  of  carrier  power  to  noise  spectral  destiny 

Clear  Mode  Control 

Coder/ Decoder 

Control  Orderwire  Master 

Communications  Security 

Control  Orderwire  Slave 

Control  Orderwire  Subsystem 

Computer  Program  Component 

Computer  Program  Configuration  Item 

Central  Processing  Unit 
Control  Segment 

Control  Terminal 
Cathode  Ray  Tube 

Continuously  Variable  Sloped  Delta  Modulation 
Cable  for  digital  transmission  groups 
Decibel 


dB 


dBM 

DBMS 

DCA 

DCAOC 

DCS 

DEFCON 

DNVT 

DRAMA 

DSCS 

DSCS/CS 

DSVT 

DT&E 

DTG 

DTMF 

DTS 

EC 

ECCM 

EIA 

EIRP 

EMC 

EOW 

EPAC 


Decibels  referenced  to  one  milliwatt  of  power 

Data  Base  Management  System 

Defense  Communications  Agency 

Defense  Communications  Agency  Operation  Center 

Defense  Communications  System 

Defense  Condition 

Digital  Non-Secure  Voice  Terminal 

Digital  Radio  and  Multiplex  Acquisition 

Defense  Satellite  Communication  System 

Defense  Satellite  Communications  System  Control  Segment 

Digital  Subscriber  Voice  Terminal 

Development  Test  and  Evaluation 

Digital  Trunk  Group 

Dual  Tone  Multiple  Frequency  -  An  AUTOVON  signalling  method 
Diplomatic  Technical  Service 
Earth  Coverage 

Electronic  Counter  Counter  Measure 

Electronics  Industries  Association 

Effective  Isotropic  Radiated  Power 

Electromagnetic  Compatibility 

Engineering  Orderwire 

Eastern  Pacific  Ocean  (satellite  network) 

Electronic  Switching  System  #4  -  Bell  System  Digital 
Tandem  Switch 


ESS4 


FDMA 


FED- STD 

FIFO 

GFE 

GFP 

GHz 

GMF 

e/T 

HAZCON 

HIPO 

HOL 

HP 

HPA 

HSD 

HT 

I  CD 

ICD-004 

ICF 

ICU 

IF 

IMU 

IND 

I/O 

IRIS 


Frequency  Division  Multiple  Access 
Federal  Standard 
First  In/First  Out 
Government  Furnished  Equipment 
Government  Furnished  Property 
Gigahertz 

Ground  Mobile  Forces 

Ratio  of  Antenna  Receiving  Gain  to  Temperature 

Hazardous  Condition  -  A  DCS  term 

Hierarchial  Input  Processing  Output 

High  Order  Language 

Historical  Profile 

High  Power  Amplifier 

High  Speed  Data 

Heavy  Terminal 

Interface  Control  Drawing 

Protocol  Specification  for  TRI-TAC 

Interconnect  Facility 

Interactive  Control  Unit  (AUTODIN  II) 

Intermediate  Frequency 

Inter  Matrix  Unit 

Indian  Ocean  (satellite  network) 

Input/ Output 

IF-RF  Interface  Subsystem 


I 


.1 


OLE 

Kbps 

KDP 

KG 

KVDT 

KY-3 

LANT 

LOW 

LRU 

MBA 

Mbps 

MCCU 

Mcl 

M/D/1 

MF2/6 

MHz 

MILOEP 

MIL-STD 

MMI 

MSF 

MTBF 

MTR 


Jammer  Location  Electronics 

Thousands  bits  per  second 

Keyboard/ Display/ Printer 

Keying  Generator 

Keyboard  Video  Display  Terminal 

Encryption  Device 

Atlantic  Ocean 

Link  Orderwlre 

Line  Replaceable  Unit 

Multi -Beam  Antenna 

Megabits  per  second 

Multiple  Channel  Control  Unit  (AUTODIN  II) 

Mean  Corrective  Time 

A  Markov  arrival  time,  discrete  service  time,  single 
server  queue 

Multiple  Frequency,  2  out  of  6  tones;  siganlling  method 
used  in  AUTOVON. 

Megahertz 

Military  Department 
Military  Standard 
Man  Machine  Interface 
Multiplex  Signal  Format 
Mean  Time  Between  Failure 
Mean  Time  to  Restore 
Mean  Time  to  Repair 


MTTR 


1 

1 

r 

NATO 

North  American  Treaty  Organization 

( 

i. 

I  ■ 

NCC 

Network  Control  Center  (AUTODIN  II) 

r 

NCE 

Network  Control  Element 

p 

NCP 

Network  Control  Processor 

• 

NCS 

Nodal  Control  Subsystem  (ATEC) 

K: 

C'. 

NCT 

Network  Control  Terminal 

>  v  *• 

* 

NRE 

Network  Reconfiguration  Engineering  (AUTODIN  II) 

OCE 

Operational  Control  Element 

Js  < 

u' 

OCP 

Operational  Control  Processor 

OMS 

Operation  and  Maintenance  Subsystem 

OT&E 

Operational  Test  and  Evaluation 

:  ■ 

1 

PABX 

Private  Automatic  Branch  Exchange 

i 

:  1 

PBER 

Pseudo  Bit  Error  Rate 

V  ^ 

PBX 

Private  Branch  Exchange 

f,  1 

r 

PCM 

Pulse  Code  Modulation 

• 

t 

»  j 

PM 

Performance  Monitoring 

PMP 

Performance  Monitoring  Program 

-  *j 

f 

PN 

Pseudo  Noise 

[■  | 

; 

-  M 

PN/TDMA 

Pseudo  Noise/Time  Division  Multiple  Access 

PSN 

Packet  Switching  Node 

j 

[  i 

PTF 

Patch  and  Test  Facility 

f  1 

QPSK 

Quadraphase  Shift  Keying 

j 

RF 

Radio  Frequency 

1 

1 

1 

'  i 

\ 

i  : 

j  t 

RFO 

Reason  for  Outage 

RSJ 


RSL 

RSS 

RTS 

SATCOM 

SB-3865 

SCAU 

SCCE 

SCCU 

SCM 

SCR 

SCS 

SDMX 

SF 

SMS 

SNCC 

SNCE 

SSMA 

SSME 

STED 

SYSCON 

TAC 

TBO 


Register  Sender  Junctor 
Received  Signal  Level 
Received  Signal  Strength 

Remote  Tracking  Station,  associated  with  the  AFSCF 
Satellite  Communications 

The  user  concentrating  switch  for  upgraded  AUTOVON/ 
AUTOSEVOCOM  II. 

SYSCON  Channel  Acquisition  Unit 

Satellite  Configuration  Control  Element 

Single  Channel  Control  Unit 

Switch  Control  Module 

Silicon  Controlled  Rectifier 

Sector  Control  Subsystem  (ATEC) 

Space  Division  Matrix 

Single  Frequency 

Satellite  Monitoring  Subsystem 

Subnetwork  Control  Center;  a  copy  of  the  NCC  serving 
European  AUTODIN  only. 

Subnet  Control  Element 

Spread  Spectrum  Multiple  Access 

Spread  Specturm  Modem  Equipment 

Seeley  Trunk  Encryption  Device  (SB- 3865) 

System  Control 

Terminal  Access  Controller 

To  be  determined 


.1 


TBP 

TBS 

TCC 

TCCF 

TCE 

TCP 

TDM 

TDMA 

TDMX 

TLC 

TM 

TRI-TAC 

TTC-39 

TTY 

TX 

UK 

ULS 

VDCU 

VOW 

WF-16 

WOFR 

WPAC 


To  be  provided 
To  be  specified 

Transmission  Control  Code  (AUTODIN  II) 

Tactical  Communications  Control  Facility 

Terminal  Control  Element 

Terminal  Control  Processor 

Time  Division  Multiplex 

Time  Division  Multiplex  Access 

Time  Division  Matrix 

Traffic  Load  Control 

Test  Mode 

The  tactical  communications  system  currently  under 
development. 

The  nodal  circuit  switch  for  upgraded  AUTOVON/AUTOSEVOCOM  II. 

Teletype 

Transmission 

United  Kingdom 

Unit  Level  Switch 

Voice  Data  Channel  Unit 

Voice  Orderwlre 

Fleldwlre  for  telephone  installations. 

WWOLS  Output  Formatting  Routines 
Western  Pacific  Ocean  (satellite  network) 

World  Wide  On-Line  System 


WWOLS 


